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The  aircrew  scheduling  problem  has  received  Considerable 
research  attention  in  the  military.  Because  of  the  great  number 
of  possible  scheduling  alternatives,  it  is  difficult  to  find  an 
optimal  solution  to -the  scheduling ■ problem.  Additionally, 
changes  to  the  original  schedule  make  it  even  more  difficult  to 
find  an  optimal  solution.  The  emergence  of  capable  microcompu¬ 
ters,  decision  support  systems,  the  adaptive  design  methodology, 
and  integrated  software  packages  has  provided  an  opportunity  to 
develop  decision  aids  to  help  aircrew  schedulers  become  more 
efficient  and  develop  more  effective  aircrew  schedules.  This 
thesis  investigates  the  development  of  a  decision  aid  to  assist 
6916ESS  Electronic  Security  Squadron  schedulers  develop  schedules 
and  make  changes  to  existing  schedules.  The  adaptive  design 
methodology  in  decision  support  systems  development  is  used  in 
the  construction  of  this  decision  aid.''  *  Storyboarding  *  and  the 
Representation,  Operations,  Memory  ,  and  Control  Aids  (ROMC) 

are  two  popular  technique^L-jj^ed  TrT^the  adaptive  design  process  to 
define  system  requirem;sfTts  and  the  decision  process  and  to  select 
the  important  sub-problems  or  ‘kernels*  as  the  starting  point  for 
system  implementation . ^ This  decision  aid  integrates  an  extensive 
data  base  and  spreadsheet  system  to  assist  schedulers  develop  and 
maintain  schedules  and  other  scheduler  functions  such  as:  flight 
orders  preparation,  30  and  90  day  flight  hour  computations,  and 
recurring  training.  The  system  is  built  using  a  Zenith  Z-248 
microcomputer  and  an  integrated  word  processing,  spreadsheet,  and 
data  base  software  package. 


Preface 


The  purpose  of  my  research  was  to  develop  a  decision  aid 
that  would  actually  be  fielded  at  the  6916ESS  and  possibly  other 
ESC  airborne  units  and  still  meet  the  thesis  academic 
requirements.  The  resulting  decision  aid  can  be  improved  in  time 
with  adherence  to  the  adaptive  design  process. 

While  building  this  decision  aid,  I  received  support  form 
several  people  which  added  substantially  to  the  quality  of  the 
decision  aid.  SSgt  Gene  Salo  from  the  6916ESS  fought  the  mail 
service  between  the  US  and  Greece  to  validate  my  understanding  of 
the  scheduling  process  at  the  6916ESS.  LtCol  French  (Frenchy) , 

HQ  ESC/XPX  found  the  time  and  TDY  funding  to  send  an  expert  to 
evaluate  the  early  design  and  development  of  the  decision  aid. 

The  expert,  CMSgt  Wally  Knox  provided  valuable  comments  on  the 
original  design  and  future  enhancements  for  the  system.  LtCol 
Skip  Valusek  provided  solid  guidance  and  almost  a  ‘free  reign'  as 
my  thesis  advisor.  Maj  Jim  Schoeck  was  instrumental  in  helping 
me  keep  the  proper  perspective  throughout  my  stay  at  AFIT.  Last 
but  by  no  means  least,  I  heartfully  appreciate  the  understanding 
and  encouragement  my  wife,  Sara,  provided  during  this  'crisis.' 

To  those  mentioned  here  and  to  everyone  else  who  helped  with  this 
undertaking,  thank  you. 
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ABSTRACT 


The  aircrew  scheduling  problem  has  received  considerable 
research  attention  in  the  military.  Because  of  the  great  number 
of  possible  scheduling  alternatives,  it  is  difficult  to  find  an 
optimal  solution  to  the  scheduling  problem.  Additionally, 
changes  to  the  original  schedule  make  it  even  more  difficult  to 
find  an  optimal  solution.  The  emergence  of  capable  microcompu¬ 
ters,  decision  support  systems,  the  adaptive  design  methodology, 
and  integrated  software  packages  has  provided  an  opportunity  to 
develop  decision  aids  to  help  aircrew  schedulers  become  more 
efficient  and  develop  more  effective  aircrew  schedules.  This 
thesis  investigates  the  development  of  a  decision  aid  to  assist 
6916ESS  Electronic  Security  Squadron  schedulers  develop  schedules 
and  make  changes  to  existing  schedules.  The  adaptive  design 
methodology  in  decision  support  systems  development  is  used  in 
the  construction  of  this  decision  aid.  * Storyboarding ‘  and  the 
Representation,  Operations,  Memory  Aids,  and  Control  Aids  (ROMC) 
are  two  popular  techniques  used  in  the  adaptive  design  process  to 
define  system  requirements  and  the  decision  process  and  to  select 
the  important  sub-problems  or  'kernels*  as  the  starting  point  for 
system  implementation.  This  decision  aid  integrates  an  extensive 
data  base  and  spreadsheet  system  to  assist  schedulers  develop  and 
maintain  schedules  and  other  scheduler  functions  such  as:  flight 
orders  preparation,  30  and  90  day  flight  hour  computations,  and 
recurring  training.  The  system  is  built  using  a  Zenith  Z-248 
microcomputer  and  an  integrated  word  processing,  spreadsheet,  and- 
data  base  software  package. 
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DESIGN  OF  AN  AIRCREW  SCHEDULING 
DECISION  AID  FOR  THE 
091OTH  ELECTRONIC  SECURITY  SQUADRON 


I  Background 


Background 

0910th  Elactronic  Security  Squadron  (6910ESS) •  The 
6916ESS  is  located  at  Hellenikon  Air  Base  near  Athens,  Greece  and 
is  a  subordinate  squadron  of  Electronic  Security  Europe,  Ramstein 
Air  Base,  Germany  and  Electronic  Security  Command ,  Kelly  Air 
Force  Base,  Texas.  The  6916ESS  provides  support  to  the  US  Navy’s 
Sixth  Fleet,  US  Air  Forces  in  Europe,  and  to  national  command 
authorities.  The  squadron  provides  aircrew  personnel  in  support 
of  the  RC- 1 35V/ W  (Rivet  Joint)  mission.  The  specific  mission  of 
the  6910ESS  is  classified.  For  the  purposes  of  this  research,  it 
is  sufficient  to  say  that  6916ESS  personnel  fly  combat  support 
missions  on  Strategic  Air  Command  aircraft  and  that  their 
missions  are  vital  to  national  security  and  the  safety  of  US 
forces  in  the  Mediterranean  area. 

Due  to  the  6916ESS'  mission  load,  crew  scheduling  is  a  daily 
requirement.  The  6916ESS'  missions  are  tasked  by  the  Joint 
Chiefs  of  Staff  and  executed  by  the  Strategic  Air  Command.  Since 
practically  every  mission  the  6916ESS  flies  is  a  combat  support 
mission,  emphasis  is  placed  on  providing  an  operationally 
qualified  crew  for  each  mission.  Secondary  emphasis  is  placed  on 
the  training  of  unqualified  operators. 

6916ESS  personnel  operate  12  standard  positions  and  several 
special  projects  positions  aboard  the  RC-135  aircraft.  The 
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squadron  is  currently  tasked  to  support  two  standing  missions  and 
contingency  operations  in  the  area.  The  6916ESS  flight  crew  is 
comprised  of  19-20  operations  personnel  and  three  to  four 
maintenance  technicians.  Thirteen  to  fourteen  of  these  personnel 
are  primary  operators.  The  remaining  five  to  seven  personnel  are 
trainees,  evaluators,  observers,  or  visitors.  Depending  on  the 
mission  being  flown,  there  are  either  thirteen  or  nine  unique 
positions  that  must  be  manned  as  shown  in  Table  1.1.  Position  1, 
position  2,  and  position  13  are  all  special  positions.  Operators 
qualified  in  these  special  positions  must  also  be  qualified  as  a 
type  3,  4,  5,  or  8  operator.  The  type  3  Lead,  4  Lead,  7  Lead, 
and  8  Lead  operators  are  also  qualified  to  fly  the  type  3,  4,  7 
and  8  positions  respectively.  Due  to  the  classification  of  the 
function  of  each  position,  further  definition  will  not  be  given. 


Table 

1.1  Aircraft  Position 

Layout 

Mission 

Type 

! 

Position  5 

2  1 

3  4  6 

7 

8 

9 

10 

11 

12 

Type  of  5 

2  1 

3  4  6 

4 

3 

7 

7 

8 

8 

Operator 

Lead  Lead 

Lead 

Lead 

Mission 

Type, 

2 

Position  5 

2  1 

3  4  6 

7 

8 

9 

10 

11 

12 

Type  of  5 

2  1 

3  4  6 

4 

4 

4 

3 

3 

3 

Operator 

Lead  Lead 

Lead 

Lead 

Organization 

The  6916ESS  Operations  Branch  is 

divided 

into 

’  day 

management  * 

functions 

and  flight 

operations 

( 

see  Fi 

8  1 

below)  . 

The  major  day  management  sections  include:  Collection  Management 
(D00) ,  Training  (DOT) ,  Standardization/Evaluation  (DOTS) , 
Computer  Resources  (DOY) ,  Support  (DOU) ,  and  Analysis  and 
Reporting  (DOA) .  Flight  operations  is  managed  by  the  Operations 
Production  (DOR)  Section.  DOR  is  responsible  for  ground 
processing  and  ensuring  each  mission  is  manned  with  a  qualified 
crew.  Therefore,  the  operations  scheduling  function  is  a  DOR 
responsibility.  DOR  is  composed  of  three  flights,  a  special 
signals  section,  and  the  operations  scheduling  section. 
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Figure  1 . 1 

Operations 

Organization 

Although  actual  manning  levels  vary,  the  6916ESS  is 
authorized  approximately  120  flying  personnel.  Table  1.2  shows 
the  division  of  the  authorized  personnel  among  the  different  type 
of  operators  and  the  average  percent  qualified.  Since  the  actual 


number  of  personnel  varies,  no  attempt  is  made  to  define  the 


actual  number  of  personnel  assigned  or  the  number  of 
qualified/unqualified  personnel  assigned  to  the  6916ESS. 

Table  1.2  6916ESS  Manning 


Operator 

Number 

Authorized 

Percent  Qua 

3 

30 

35-50 

4 

30 

35-50 

5 

10 

70-80 

0 

10 

70-80 

7 

20 

35-50 

8 

— 

20 

35-50 

Total 

120 
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hours  of  post-mission  crewrest  which  may  run  concurrently. 
Operators  are  subject  to  Duty  Not  Including  Flying  (DNIF)  for 
physical  and  mental  illness.  Currency  in  several  periodic 
refresher  training  areas  must  be  maintained  or  operators  are 
ineligible  for  flying  duties.  Leaves,  TDYs ,  and  miscellaneous 
appointments  also  affect  an  operator’s  availability  to  fly  a 
particular  mission.  Schedulers  must  keep  track  of  all  these 
availability  factors  when  completing  a  mission  crew  to  prevent 
scheduling  operators  who  are  not  available  or  not  qualified. 


changes.  Although  the  number  of  changes  vary  from  month  to  month, 
0916ESS  schedulers  can  expect  an  average  of  about  8-12  mission 
schedule  changes  per  month  with  a  lead  time  between  receiving  the 
schedule  change  and  mission  execution  ranging  from  several  days 
to  13  hours. 

0916ESS  schedulers  begin  scheduling  mission  crews  a  week  to 
two  weeks  in  advance.  The  flight  which  is  working  the  day  shift 
is  responsible  for  manning  most  of  the  mission  crew  positions  for 
normal  missions.  Since  each  flight  works  three  day  shifts  before 
changing  to  swing/mid  shifts,  schedulers  normally  work  on  a 
maximum  of  three  missions  at  a  time. 

Hard  Scheduling  Crewmembers.  The  scheduler  starts  with  any 
crewmembers  that  must  be  'hard  scheduled*  for  a  particular 
mission.  Crewmembers  who  are  hard  scheduled  include: 

1)  Standardization/evaluation-  (Stan/Eval)  evaluations 

2)  Observers 

Stan/Eval  evaluation  schedules  are  developed  by  the 
Stan/Eval  section  and  are  provided  to  the  schedulers  either 
verbally  or  via  handwritten  note.  The  Stan/Eval  section  provides 
the  mission,  date,  evaluator's  name,  and  evaluatee's  name. 

Observers  are  crewmembers  who  observe  the  crew  for  proper 
performance  and  compliance  with  procedures  but  do  not  have  a 
specific  function  during  the  mission.  Squadron  observers  include 
the  Squadron  Commander,  Operations  Officer,  Maintenance  Officer, 
and  off icer  section  chiefs  in  the  Operations  Branch. 

FllMht  Commander  Recommendations.  After  the  required  hard 
schedules  are  complete,  the  schedulers  incorporate  the  scheduling 


recommendations  provided  by  the  Flight  Commander.  Flight 
Commander's  recommendations  include: 


I 


\ 

I 

! 


F* 

W*i 


1)  Which  trainees  should  fly  on  which  missions 

2)  Which  trainers  should  train  the  trainees 

3)  Which  other  operators  should  fly  on  which  missions 
Flight  supervisors  help  their  Flight  Commander  prepare  the  Flight 
recommendations.  The  schedulers  will  comply  with  the  Flight 
Commander's  recommendations  as  much  as  possible. 

Airborne  Mission  Supervisor  and  Airborne  Analyst.  From  the 
Flight  Commander’s  recommendations,  the  schedulers  turn  their 
attention  to  matching  operators  to  positions.  This  process 
normally  starts  with  the  Airborne  Mission  Supervisor  (AMS)  and 
Airborne  Analyst  positions  since  fewer  operators  are  normally 
qualified  to  fly  these  positions  than  the  other  positions. 

Trainees  and  Trainers.  Next,  the  schedulers  select  the 
trainees  for  each  mission.  There  are  normally  five  to  seven 
seats  allocated  to  trainees.  When  selecting  trainees,  the 


K' 


schedulers  consider  the  Flight  Commander’s  recommendations,  other 
squadron  management  recommendations  and  directives,  and  their  own 
judgement.  If  there  is  a  conflict,  the  schedulers  ask  the  Chief 
of  Operations  Production  (DOR)  for  resolution. 

After  the  trainees  have  been  scheduled,  the  schedulers  must 
match  a  trainer  to  each  trainee.  The  scheduler  again  considers 
the  Flight  Commander’s  recommendations  along  with  other  squadron 
management  recommendations,  directives,  and  his  personal 
judgement.  The  schedulers  first  check  the  responsible  flight’s 
resources  to  fill  the  trainer  requirements.  If  there  are 
unfilled  requirements,  the  schedulers  consider  available  day 
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management  qualified  trainers.  If  there  are  still  unfilled 
requirements,  the  schedulers  must  evaluate  if  the  training 
received  by  the  trainee  is  important  enough  to  task  a  trainer 
from  the  swing/mid  shift  to  fly.  In  this  situation,  the  operator 
from  the  swing/mid  shift  will  be  lost  to  his  flight  for  two 
shifts.  As  a  result,  ground  processing  and  training  will  suffer 
on  the  swing/mid  shift  flight.  As  expected,  this  option  is  used 
very  infrequently  and  only  in  extenuating  circumstances . 

If  unfilled  trainer  requirements  remain,  the  scheduler  must 
select  a  different  type  of  trainee.  Once  the  trainee  is 
selected,  the  scheduler  must  find  a  proper  trainer.  The  same 
procedure  described  above  is  followed  until  all  trainees  are 


matched  with  trainers. 


r.  The  scheduler’s  next  step 


is  to  man  the  remaining  mission  crew  positions.  Again,  the 

scheduler  uses  the  Flight  Commander's  recommendations  as  a 
« 

starting  point.  Day  management  operator  availability  is  checked 
to  complete  positions  not  filled  by  the  primary  (day  shift) 


flight. 


Even  though  a  mission  crew  has  been 


scheduled,  it  will  constantly  change  before  the  mission  is 
executed.  Crew  changes  may  be  caused  by  changes  m: 

1)  Operator  availability 

2)  Mission  type 

3)  Takeoff  times 

4)  Mission  priorities 

5)  Mission  duration 
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6)  Failed  evaluations  (requires  remedial  training 


flights  for  the  trainee  who  failed  and  is  a  high  priority) 

7)  Squadron  management  decisions 

When  a  mission  crew  change  is  required,  the  scheduler  must 
replace  the  operator(s).  He  first  checks  the  responsible  flight 
for  available  operators.  If  no  match  is  made,  day  management 
operator  availability  is  checked.  If  no  replacement  is  found 
from  the  day  management  operators,  the  scheduler  will  schedule  an 
operator  working  the  swing/mid  shift  or  who  is  on  break  as  a  last 
resort.  Mission  crew  changes  may  result  in  other  changes  with 
that  mission  crew  (e.g.  if  a  trainer  becomes  unavailable  and  no 
other  trainer  is  available,  the  trainee  must  be  scratched  and  a 
new  type  of  trainee  and  trainer  found  if  possible).  Also, 
changes  may  affect  another  mission  crew  (e.g.  the  only  available 
replacement  is  also  scheduled  to  fly  the  next  day.  If  there  is 
less  than  12  hours  for  crew  rest  available  between  missions,  a 
replacement  must  be  found  for  the  next  days ’ s  mission) . 

Mlolon  Planning  Sheet  and  Flliht  Orders-  The  day  before  a 
mission  is  scheduled  to  fly  (2  days  prior  for  Sunday  missions  and 
3  days  prior  for  Monday  holiday  missions)  the  scheduler 
circulates  the  Mission  Planning  Sheet  (MPS)  to  the  Operations 
Production,  Operations  Training,  and  Standardization/Evaluation 
Sections  and  then  to  the  Operations  Officer.  This  is  the  last 
opportunity  (in  theory)  for  squadron  management  to  make 
recommended  or  directed  changes  to  a  mission  crew.  After  the  MPS 
is  signed  by  the  Operations  Officer,  the  scheduler  makes  up  the 
flight  orders.  After  the  flight  orders  are  finished,  the  only 
way  the  mission  crew  will  normally  change  is  due  to  operator 


illness.  As  mentioned,  the  6916ESS  does  receive  last  minute 
mission  changes  which  could  require  a  mission  crew  change. 
However,  these  type  of  changes  are  somewhat  infrequent  and  depend 
on  the  area  situation.  During  times  of  turmoil,  last  minute 
changes  may  occur  10-12  times  a  month. 

Post  Mission  Duties.  Once  the  mission  has  been  completed, 
the  scheduler  must  update  each  operator’s  flight  card  which 
includes  updates  to  the  30  and  90  day  flight  hours. 

The  scheduler  is  also  required  to  review  the  training 
reports  written  on  the  trainees  so  that  he  is  familiar  with  their 
progress  and  can  make  proper  judgements  when  scheduling  them  to 
fly. 

Memory  Aids.  The  schedulers  have  devised  several  manual 
memory  aids  to  help  them  during  the  scheduling  process .  The  wall 
outside  of  the  scheduler’s  office  holds  the  plexiglass  scheduling 
boards.  There  is  space  for  a  total  of  14  mission  crews  to  be 
posted.  For  each  mission,  there  is  space  for  the  mission  date, 
mission  number,  mission  type,  and  a  block  for  each  crewmember's 
name.  The  schedulers  also  have  a  plexiglass  board  to  keep  track 
of  operator  availability.  This  board  is  divided  into  areas  for 
DNIFs,  leaves,  TDYs ,  and  miscellaneous  appointments. 

As  mentioned  earlier,  the  schedulers  maintain  flight  cards 
which  contain  information  on  each  flight  an  operator  has  flown 
such  as  the  date  and  the  flight  duration.  The  flight  cards  also 
have  a  running  total  of  each  operator's  30  and  90  day  flight 
hours.  The  flight  cards  are  sorted  by  operator  type  and 


alphabetical ly . 


Schedulers  keep  an  incredible  amount  of  information 
concerning  each  operator’s  qualifications  in  their  memory.  To 
help  the  schedulers  and  other  squadron  personnel ,  the  Training 
and  Stan/Eval  Sections  publish  a  letter  each  month  which  details 
each  operator's  qualifications.  Additionally,  the  Training 
Section  publishes  a  monthly  letter  detailing  the  status  of  each 
trainee.  Information  in  this  letter  includes  the  trainee's 
qualification,  number  of  training  flights  received,  and  time 
remaining  before  an  evaluation  is  due.  Since  these  letters  are 
published  monthly,  they  become  quickly  outdated,  forcing  the 
scheduler  to  rely  on  his  memory. 

Miscellaneous  Functions.  0916ESS  schedulers  must  schedule 
other  functions  which  impact  operator  availability.  Each  operator 
must  complete  periodic  physiological,  special  survival,  and  life 
support  refresher  training  to  remain  on  flight  status. 

Schedulers  must  keep  track  of  who  requires  which  type  of  training 
and  are  the  focal  point  for  scheduling  operators  for  required 
training.  Operators  require  physiological  refresher  training 
every  three  years.  Since  physiological  refresher  training 
requires  a  TDY  to  Germany  and  the  number  of  openings  for  each 
refresher  class  is  limited,  schedulers  must  forecast 
physiological  refresher  training  requirements  well  in  advance. 
Special  survival  refresher  training  is  required  every  18  months 
and  life  support  training  every  six  months.  Both  types  of 
refresher  training  are  conducted  at  Hellenikon  AB .  Squadron 
schedulers  maintain  a  list  of  which  operators  require  refresher 


training  and  schedule  them  to  attend  training. 

Another  requirement  to  stay  on  flight  status  is  a  current 


flight  physical.  Every  operator  must  have  a  flight  physical 
completed  every  year  by  the  last  day  of  their  birth  month. 

Physicals  may  be  accomplished  as  much  as  two  months  prior  to  an 
operator’s  birth  month.  Although  squadron  schedulers  are  not 
required  to  schedule  flight  physicals,  they  are  required  to 
monitor  each  operator’s  flight  physical  status. 

Research  Problem 

Aircrew  scheduling  is  a  problem  area  at  the  0916ESS  because 
of  the  dynamic  environment  and  the  number  of  variables  involved 
in  the  aircrew  scheduling  decision  process.  Although  squadron 
schedulers  have  done  a  good  job  with  their  manual  methods,  it  may 
be  beneficial  to  investigate  computer  aids  for  their  decision 
processes . 

. ObJ  gctjyea 

1)  To  initiate  a  decision  aid  to  help  6916ESS  schedulers  become 
more  efficient  and  produce  better  aircrew  schedules. 

2)  To  investigate  adaptive  design  as  a  process  to  help 
build  the  scheduling  decision  aid. 

Chapter  II  discusses  past  solution  attempts  for  the  aircrew 
scheduling  problem,  decision  support  systems  in  general,  and  the 
general  adaptive  design  methodology. 
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II  METHODOLOGY 


Introduction 

This  chapter  begins  by  discussing  past  military  research 
solution  attempts  for  the  aircrew  scheduling  problem  and  the 
general  inadequacies  of  that  past  research.  Chapter  II  then 
discusses  decision  support  systems  in  general  and  the  adaptive 
design  methodology  used  to  build  many  decision  support  systems. 

Past  Solution  Attempts 

Numerous  theses  concerning  aircrew  scheduling  have  been 
written  since  1980.  The  most  flexible  and  dynamic  effort  was 
completed  by  Drowley  in  1984.  The  Drowley  thesis  is  a  computer 
program  which  seeks  to  help  schedulers  in  a  USAF  fighter  squadron 
optimize  resources  for  maximum  crew  training.  Drowley  focuses  on 
an  F-15  squadron  with  a  single  mission  and  one  aircrew  position. 
The  foundation  of  Drowley’s  computer  system  is  the  weekly 
scheduling  shell  which  includes:  type  of  flights,  takeoff  and 
landing  times.  Supervisor  of  Flying  duties.  Runway  Supervisor 
Officer  duties,  and  Squadron  Duty  Officer  duties. 

Drowley  also  developed  several  data  bases.  The  pilot 
accomplishments  and  flight  currency  data  base  includes 
information  on  the  number  of  sorties  pilots  have  accomplished  and 
have  remaining  by  type,  the  last  time  a  pilot  completed  an  event, 
and  the  currency  requirement  for  each  event.  The  pilot 
qualifications  data  base  includes  pilot  training  status,  level  of 
flight  qualifications,  supervisory  status,  and  availability. 

Drowley’s  computer  program  has  several  subprograms.  The 


first  subprogram  allows  schedulers  to  manually  input  data  about 
pilots  who  are  not  available  due  to  DNIF,  meetings,  appointments, 
TDY,  and  leave.  The  main  program  uses  several  procedures  to  sort 
through  the  data  base  and  matches  pilots  to  missions  and 
additional  duties.  One  of  Drowley's  most  important  measures  is  a 
pilot's  need  for  a  particular  mission.  This  need  is  calculated 
by  dividing  the  number  of  events  accomplished  by  the  number  of 
events  required  (7) . 

Sahli  and  Shacklett  developed  a  Decision  Support  System  for 
a  special  operations  C-130  squadron.  They  concentrated  on  pilots 
and  copilots.  As  with  the  Drowley  thesis,  Sahli  and  Shacklett 
manipulated  data  base  information  to  develop  a  flight  schedule. 
This  thesis  also  concentrated  on  pilot  proficiency,  however, 

Sahli  and  Shacklett  defined  a  pilot's  ‘need*  as  the  number  of 
events  remaining  to  be  accomplished  rather  than  the  ratio  of 
events  accomplished  to  the  number  required  (19). 

Roege’s  thesis  in  1983  concentrated  on  scheduling  by  meeting 
training  and  proficiency  requirements  contained  in  Tactical  Air 
Command’s  Manual  (TACM)  51-50.  As  with  the  Drowley  thesis, 
Roege’s  thesis  concentrated  on  an  F-15  air-to-air  squadron. 

Roege  formulated  the  problem  as  an  assignment  problem.  The 
objective  was  to  assign  pilots  to  duties  at  a  specified  cost 
subject  to  crew  rest  constraints.  Roege  solved  the  problem  using 
integer  programming.  Roege  used  the  requirements  in  TACM  51-50  to 
form  an  objective  function.  The  costs  were  defined  as  the 
percentage  of  requirements  completed.  By  minimizing  this 
function,  Roege's  program  schedules  those  pilots  who  are  behind 


in  fulfilling  requirements  at  the  expense  of  pilots  who  are  ahead 
(18)  . 

Berman  developed  the  Decision-Oriented  Support  System 
(DOSS) .  DOSS  is  a  heuristic  approach  to  solving  scheduling 
problems.  DOSS  allows  interactive  computing  with  access  to  a 
large  data  base  enabling  the  user  to  compare  alternative 
schedules.  Berman  used  payoff  points,  a  form  of  weighting 
alternatives  (19:16). 

Follon  improved  Berman’s  work  by  developing  different  rules 
for  sequencing  activities.  Follon’s  rules  take  the  form  of 
assigning  a  need  indicator  to  each  aircrew  competing  for  a 
sortie.  Both  Berman's  and  Follon’s  systems  required  the  use  of 
large  mainframe  computers  (19:17). 

Pease  developed  the  Automated  Command  Support  (ACS.l) 
system.  Pease  developed  a  matrix  with  the  days  of  the  week  as 
the  columns  and  pilots  as  the  rows.  Pilot  availability  and  a 
payoff  were  annotated  in  the  cells.  The  scheduler  could  then 
quickly  see  which  pilots  should  be  scheduled  for  flights 
(19: 19)  . 

For  their  thesis,  Banbridge  and  Cioli  developed  a  model  to 
analyze  aircrew  scheduling  payoffs.  This  model  identified 
aircrews  which  required  increased  or  decreased  sorties  to  meet 
minimum  flying  hour  requirements.  Although  this  thesis  developed 
a  way  to  identify  a  need,  it  did  not  address  the  problem  of 
assigning  preferences  between  aircrews  for  a  particular  sortie 
(19:21) . 

Egge  addressed  the  deficiency  of  establishing  preferences  in 
the  Bainbridge  and  Cioli  thesis.  Egge  calculated  a  payoff  value 
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using  the  ratio  of  accomplished  tasks  to  required  tasks  and  the 
time  remaining  to  accomplish  the  tasks.  This  payoff  value 
equated  to  an  aircrew's  need  for  a  sortie  in  relation  to  all 
other  aircrews  (19:21). 

Inadequacies  of  Past  Solution  Efforts.  A  considerable 
amount  of  research  has  addressed  the  Air  Force  aircrew  scheduling 
problem.  Early  efforts  involved  attempts  to  apply  linear 
programming  to  a  static  scheduling  environment  using  mainframe 
computers.  A  special  application  of  linear  programming,  the 
assignment  problem,  and  integer  programming  have  also  been  used 
in  an  attempt  to  solve  the  scheduling  problem.  These  attempts 
have  succeeded  when  the  scheduling  environment  is  treated  as 
static.  More  recent  research  has  addressed  the  scheduling 
problem  using  microcomputers.  These  efforts  have  begun  to 
address  the  many  variables  involved  in  the  scheduling  problem  and 
have  also  introduced  more  flexibility  for  the  scheduler  using  the 
system.  The  vast  majority  of  research  thus  far  has  been  directed 
toward  Air  Force  fighter  squadrons  with  single  seat  aircraft  and 
have  concentrated  on  maintaining  pilot  proficiency  and  upgrading 
unqualified  pilots.  No  research  has  addressed  the  process  of 
scheduling  multiple  crewmembers  for  operational  missions. 

Past  research  concerning  the  aircrew  scheduling  problem  has 
placed  little  emphasis  on  the  dynamic  scheduling  environment. 

The  dynamic  scheduling  environment  requires  a  flexible  system  to 
provide  the  scheduler  a  choice  and  to  take  advantage  of  his 
judgment.  Because  of  the  flexibility  required  to  be  effective  in 
a  dynamic  environment,  a  program  or  system  which  tries  to 


accomplish  the  entire  scheduling  process  with  a  "one  push  of  the 
button'  approach,  does  not  seem  to  be  the  answer  to  the  total 

problem.  Although  the  initial  schedule  might  be  developed  using  1 

the  'one  push  of  the  button"  approach,  the  system  must  also  3 

provide  the  capability  to  make  rapid  changes  easily.  Therefore, 
a  system  that  is  flexible,  adaptable,  and  that  supports  the 
scheduling  process  seems  to  be  more  appropriate. 


Decision  Support  Systems 

A  promising  approach  to  developing  a  scheduling  decision  aid 
is  the  adaptive  design  or  prototyping  process  used  in  building 
Decision  Support  Systems.  The  field  of  Decision  Support  Systems 
is  still  relatively  new.  As  such,  there  is  no  standard 
definition  for  a  DSS .  Alavi  and  Napier  define  a  DSS  as  'computer 
based  systems  designed  to  enhance  the  effectiveness  of  decision 
makers  in  performing  semi-structured  tasks .  With  such  tasks,  the 
decision  maker  is  uncertain  about  the  nature  of  the 
problem/opportunity,  the  alternative  solutions,  and/or  the 
criteria  or  value  for  making  a  choice.  Hence,  the  primary  role 
of  a  DSS  is  to  aid  the  judgment  processes  as  the  decision  maker 
contends  with  poorly  defined  problems'  (15:21).  Ford  says  DSSs 
should  be  designed  to  emphasize  direct  support  for  decision 
makers  in  order  to  enhance  the  professional  judgments  required  in 
their  decision  making  (8:21).  Davis  defines  the  purpose  of  a  DSS 
as  a  way  to  couple  the  speed  and  thoroughness  of  automation  with 
the  insight  of  human  experience,  while  adding  the  proper  blend  of 
quantitative  support.  According  to  Hill  and  Watson,  'a  DSS  is  an 
interactive  system  that  provides  the  user  with  easy  access  to 
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decision  models  and  data  in  order  to  support  semi -structured  and 
unstructured  decision-making  tasks'  (12:82).  Instead  of  defining 
what  a  DSS  should  be  or  do,  Keen  and  Morton  describe  what  a  DSS 
should  not  do.  That  is,  a  DSS  is  'a  supportive  tool  which  does 
not  attempt  to  automate  the  decision  process,  pre-define 
objectives,  or  impose  solutions'  (11).  Sprague  and  Carlson 
prefer  to  define  a  DSS  in  terms  of  characteristics  DSSs  should 
have : 

'1.  They  tend  to  be  aimed  at  the  less  well  structured, 
underspecified  problems  that  upper-level  managers  typically  face. 

2.  They  attempt  to  combine  the  use  of  models  or 
analytic  techniques  with  traditional  data  access  and  retrieval 
functions . 

3.  They  specifically  focus  on  features  that  make  them 
easy  to  use  by  non-computer  people  in  an  interactive  mode. 

4.  They  emphasize  flexibility  and  adaptability  to 
accommodate  changes  in  the  environment  and  decision  making 
approach  of  the  user’  (5:6). 

Keen  and  Morton  list  their  characteristics  of  a  DSS  as: 

"1.  Assist  managers  in  their  decision  processes  in 
semi -structured  tasks 

2.  Support,  rather  than  replace  managerial  judgment 

3.  Improve  the  effectiveness  of  decision-making  rather 
than  its  efficiency’  (11) 

Sprague  and  Carlson  list  both  a  restrictive  and  a  broad 
definition  in  their  book.  Restr ictively  ,  DSSs  are  interactive 
computer-based  systems  that  help  decision  makers  utilize  data  and 
models  to  solve  unstructured  problems.  Broadly  speaking,  DSSs 


are  any  system  that  makes  some  contribution  to  decision  making. 
Perhaps  the  best  definition  of  a  DSS  as  it  pertains  to  the 
aircrew  scheduling  decision  process  is  given  by  Valusek  as:  *a 

system,  manual  or  computerized,  that  aids  a  decision  maker  in  the 
cognitive  processes  of  judgment  and  choice  (21).* 

The  terms  semi -structured  and  unstructured  problems  are  key 
to  several  of  the  DSS  definitions,  however,  rarely  are  these 
terms  explained.  Burleson,  Xassicieh,  and  Lievano  with  the  help 
of  Simon  define  unstructured  problems  as  those  problems  which 
have  time  constraints,  a  need  for  intuitive  inputs,  require  a 
large  search,  or  there  is  some  uncertainty  about  some  of  the 
decision  parameters  (4:57).  Meador  and  Rosenfeld  define  a  semi- 
structured  decision-making  environment  as  an  environment  not 
well  enough  understood  to  permit  a  complete  analytical 
description.  This  implies  the  need  to  combine  managerial 
experience  and  judgment  with  computer  based  approaches  (16:160). 


Adaptive  Design 

To  effectively  develop  a  Decision  Support  System,  a  flexible 
approach  must  be  taken.  During  the  past  several  years  research 
.and  applications  in  the  DSS  field  have  resulted  in  the 
development  of  the  adaptive  design  approach  to  developing  a  DSS. 
Alavi  and  Napier  state  that  generally  DSS  designers  have 
recognized  that  the  circumstances  requiring  a  DSS  call  for  a 
departure  from  the  traditional  systems  development  approach. 

This  departure  is  caused  in  part  by  the  inability  of  users  to 
specify  their  requirements  and  define  their  decision  problem 
(15:22).  Mahmood  and  Medewitz  believe  the  traditional  system 


2-7 


•>  .■  ..v  .y»L' 


*  -  *  -  »-■.«*. 


development  life  cycle  has  been  troublesome,  complex,  costly,  and 
time  consuming,  especially  when  applied  to  information  systems. 
They  also  lay  the  blame  on  problems  in  problem  and  requirements 


definition.  They  state:  "communication  between  the  users  of  the 

system  and  the  systems  analysts  has  been  a  particularly  difficult 
problem,  especially  in  the  crucial  stages  of  identifying  system 
performance  requirements.  Recently,  there  has  been  increased 
interest  in  prototyping  as  a  more  efficient  way  of  defining  the 
system  requirements  and  enhancing  these  communications  links' 
(15:138).  Mahmood  and  Medewitz  go  on  to  state  that  "the 
flexibility  required  for  DSS  make  the  traditional  system 
development  life  cycle  approach  inappropriate  and  difficult.  DSS 
require  the  articulation  of  a  new  design/development  approach 
which  supports  the  flexibility  they  must  have"  (15:138).  Alavi 
also  believes  the  adaptive  design  approach  with  prototyping 
should  be  used  when  faced  with  ambiguous  requirements.  This 
approach  seems  to  be  quite  effective  in  helping  decision  makers 
define  their  problems  and  clarify  fuzzy  requirements.  Sprague 
and  Carlson  explain  their  reasoning  for  a  new  development 
approach  by  stating:  "Because  there  is  no  comprehensive  theory 

of  decision-making,  and  because  of  the  rapidity  of  change  in  the 
conditions  that  decision  makers  face,  the  traditional  approaches 
for  analysis  and  design  have  proven  1 nadequate . . . Des 1 gners 
literally  cannot  get  to  first  base  because  no  one,  least  of  all 
the  decision  maker  or  user,  can  define  in  advance  what  the 
functional  requirements  of  the  system  should  be"  (5:  15)  . 

The  traditional  systems  development  approach  takes  the  form 


A 


The  traditional  systems  development  approach  takes  the  form 


of  four  distinct  steps  or  phases: 


1.  Requirements  analysis 


2.  Design 


3.  Development 


4.  Implementation 


The  basic  adaptive  design  approach  is  to  combine  the  four  phases 


of  the  traditional  systems  development  approach  into  one  single 


phase  which  is  iteratively  repeated  in  relatively  short  cycles 


(5:137-139).  Most  definitions  of  adapative  design  are  variations 


from  this  theme.  Courbon’s  Evolutive  Design  is  very  similiar  to 


adaptive  design  as  described  by  Mahmood  and  Medewitz.  Evolutive 


Design  is  ‘a  methodology  based  on  progressive  design  of  a  DSS , 


going  through  multiple  as-short-as-possible  cycles,  in  which 


successive  versions  of  the  system  under  consideration  are 


utilized  by  the  end-user*  (15:140).  The  four  steps  of  the 


Evolutive  Design  methodology  are: 


1.  Identify  an  important  sub-problem.  The  objective 


of  this  step  is  to  provide  some  immediate  relief  to  the  problem 


which  will  hopefully  help  establish  the  decision  makers 


confidence  in  the  system  and  to  set  up  a  good  working 


relationship  between  the  designer  and  the  decision  maker.  This 


important  sub-problem  is  also  called  the  ‘kernel.* 


2.  Quickly  develop  a  small  but  usable  system  to  assist 


the  decision  maker.  The  objective  of  this  step  is  to  provide  a 


system  the  user  can  employ  quickly.  The  system  may  not  have 


elaborate  capabilities,  but  will  help  during  the  decision-making 


process.  The  designer  and  the  user  do  not  neglect  the 
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traditional  systems  development  approach,  but  they  do  try  to 
minimize  the  time  required  to  go  through  these  stages. 

3.  Refine,  expand,  and  modify  the  system.  During  this 
step,  the  designer  or  builder  modifies  the  system  as  a  result  of 
inputs  from  the  user. 

4.  Evaluate  the  system  constantly.  This  is  the 
control  mechanism  for  the  evolutive  method.  If  the  DSS  does  not 
meet  the  user's  needs,  renewed  efforts  are  made  to  improve  the 
sys  tern  (15:141)  . 

The  steps  in  Sprague  and  Carlson’s  adaptive  design  method 
are  similiar  to  Courbon’s: 

1.  User  and  builder  agree  on  a  small  but  significant 
sub-problem; 

2.  Design  and  develop  an  initial  system  to  support  the 
decision-making  that  it  requires; 

3.  After  a  short  period  of  use  (a  few  weeks) ,  this 
system  is  evaluated,  modified,  and  incrementally  expanded; 

4.  This  cycle  is  repeated  three  to  six  times  over  the 
course  of  a  few  months  until  a  relatively  stable  system  evolves 
(5: 140)  . 

When  this  general  methodology  is  applied  in  designing  a 
specific  DSS,  the  following  steps  should  be  followed: 

1.  Version  0  --  an  initial  usable  system.  The 
starting  system  should  support  a  small  problem  or  a  small  part  of 
a  bigger  problem. 

2.  The  system  i3  modified  through  successive  cycles 
and  versions  1  through  S. 
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Version  S  1*  a  relatively  satisfactory  version 


3  . 

which  than  bacomes  somewhat  stable.  The  frequency  of 
modification  and  incremental  change  cycles  will  decrease  but  will 
not  stop  (5 : 141) . 

Belardo  provides  a  graphical  representation  of  this  process 
in  Figure  2.1  (3:96). 

Keen  provides  a  structure  for  the  DSS  adaptive  design 
methodology  consisting  of  the  user,  builder,  and  the  technical 
system  (DSS).  Specifically,  the  interfaces  between  these  three 
components  provide  the  framework  within  which  the  rapid  cycles 
may  take  place.  The  user  -  system  interface  concerns  the  effect 
a  user’s  character istics  have  on  system  utilization.  As  a  result 
of  interaction  with  the  system,  the  user’s  understanding 
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Figure  2.1  Adaptive  Design  Process 
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of  the  decision  process  and  potential  solutions  increases.  The 
builder  -  system  interface  occurs  as  the  builder  adds  and 
modifies  capabilities  and  functions  to  the  system.  The  user  - 
builder  interface  involves  healthy  communication  and  cooperation 
during  the  development  process.  As  a  matter  of  fact  good 
communications  between  the  user  and  the  builder  is  the  key  to 
successful  DSS  development  (5:21). 

Sprague  and  Carlson  list  several  mechanisms  which  aid  the 
adaptive  design  method: 

1.  Definition  of  roles  --  definition  of  who  the  user, 
builder,  and  technical  support  people  are 

2.  The  technology  --  the  need  to  build  a  small  usable 
system  and  change  it  constantly  places  difficult  demands  on 
technology.  Advances  in  technology,  specifically  in  the  area  of 
DSS  generators  have  made  the  iterative  nature  of  adaptive  design 
feasible . 

3.  Communication  mechanisms  --  because  of  the 
compressed  sequence  of  steps  and  rapid  cycling  of  adaptive 
design,  communications  between  the  user  and  the  builder  are  very 
important.  A  system  developed  to  provide  documentation  of  user 
requested  or  desired  changes  is  essential  if  the  system  is  to 
develop  to  its  potential. 

4.  Documentation  capability  --  a  dynamic  documentation 
capability  is  required.  Since  the  DSS  will  evolve  quickly  with 
new  capabilities  being  added  constantly,  a  system  journal  or 
diary  is  required  to  document  the  current  system  configuration. 
This  journal  is  also  a  good  source  of  past  attempts  in  developing 
system  capabilities. 
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5.  Evaluation  and  tracking  --  in  order  to  determine  if 
the  DSS  is  effective,  proper  evaluation  criteria  must  be 
developed  for  the  DSS  (5:142-144). 

BOMC 

One  of  the  primary  reasons  the  adaptive  design  methodology 
was  developed  is  the  inability  of  users  to  define  their  decision 
processes  and  requirements.  Decision  makers  have  a  difficult 
time  describing  their  decision  processes.  However,  they  do  seem 
to  rely  on  conceptualizations  (e.g.  like  pictures,  graphs,  and 
charts)  when  making  or  explaining  a  decision  (5:98) .  An 
effective  method  of  helping  the  user  to  define  his  requirements 
is  with  the  use  of  the  Representation,  Operation,  Memory  aids, 
and  Control  mechanisms  (ROMC)  method  (5:100).  The  objective  of 
the  ROMC  approach  is  to  help  reduce  the  differences  between  the 
requirements  of  decision-making  and  decision  makers,  and  the 
capabilities  of  the  DSS.  ROMC  is  especially  useful  in  situations 
where  a  decision  maker  cannot  specify,  or  can  only  partially 
specify,  the  requirements  of  a  decision  in  advance  (5:116). 
Sprague  and  Carlson  define  the  ROMC  method  as  a  decision  process 
independent  approach  for  identifying  the  necessary  capabilities 
of  a  specific  DSS.  ROMC  is  a  tool  to  focus  the  system  builder 
before  the  actual  design  of  the  DSS  (5: 100-107) . 

The  framework  for  the  ROMC  approach,  as  one  might  suspect, 
is  contained  in  the  representations,  operations,  memory  aids,  and 
control  mechanisms  decision  makers  identify  as  being  associated 
with  their  decision  process. 

REPRESENT ATI0NS :  Provide  the  context  in  which  decision 
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makers  can  interpret  outputs  and  invoke  operations.  The 
representations  are  developed  in  terms  of  Simon’s  Intelligence, 
Design,  and  Choice  decision  activities  and  can  be  used  as  a 
vehicle  to  conceptualize  and  communicate  the  decision  situation. 

OPERATIONS:  Provide  an  opportunity  to  analyze  and 

manipulate  the  representations.  This  process  can  also  be  used  to 
identify  operations  the  decision  maker  would  like  to  see 
integrated  into  the  DSS .  Besides  basic  manipulations  of  the 
representations,  operations  can  also  take  the  form  of  more 
complex  functions  or  models  like  forecasting,  simulation,  linear 
programming,  etc.  Identifying  the  intelligence,  design,  and 
choice  activities  associated  with  the  decision  process  is  a 
useful  way  of  developing  operations.  Typical  intelligence, 
design,  and  choice  activities  are  listed  in  Table  2.1. 

MEMORY  AIDS:  Employ  representations  and  operations  to 
support  the  use  of  operations  and  representations.  Memory  aids 
may  take  the  form  of  workspaces,  notepads,  data  bases,  default 
profiles,  etc. 

CONTROL  AIDS:  Formalizes  a  decision  process  using 
representations,  operations,  and  memory  aids.  Control  aids  are 
intended  to  help  a  decision  maker  use  the  representations, 
operations,  and  memory  aids  during  the  decision  process.  They 
may  take  the  form  of  the  user  -  system  interface,  user  manuals, 
training  manuals,  menus,  function  keys,  error  messages,  help 
commands ,  and  procedure  construction  capabilities  to  combine 
multiple  operations  on  one  or  more  representations  or  to  develop 
new  operations  (5:102-107). 
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Gather  data 


Gather  data  Generate  statistics/ 

alternatives 

Manipulate  data  Simulate  results  of 

alternatives 

Quantify  objectives  Explain  alternatives 


Identify  objectives  Manipulate  data 


Diagnose  problem 
Validate  data 

alternatives 
Structure  the 
problem 


Generate  reports 


Generate 
alternatives 
Assign  risks/values 
to  alternatives 


Choose  among 


Explain  the  choice 


Taken  from  Sprague  and  Carlson  p.  104 


Evaluation 


The  whole  principle  behind  the  adaptive  design  approach  is 
to  continually  modify  the  system  to  meet  the  user’s  needs.  In 
order  to  more  effectively  define  where  the  DSS  i3  and  is  not 
meeting  the  user’s  needs,  the  DSS  must  be  constantly  evaluated. 

If  the  DSS  is  not  evaluated  during  the  design  and  implementation, 
it  may  not  be  done  at  all  or  it  will  just  be  a  confirmation  that 
the  system  either  does  or  does  not  aid  the  decision  maker 
(5: 158)  . 

The  evaluation  of  DSS  success  or  effectiveness  is  a 
complicated  and  difficult  task  because  of  the  difficulty  in 
quantifying  how  much  the  DSS  helps  the  decision  maker.  The  most 
commonly  used  indicators  of  success  for  computer  based 
information  systems  are  system  usage  and  user  attitudes  and 
perceptions.  The  moat  commonly  used  measure  of  success  is  the 
user's  satisfaction  with  the  capability  of  their  system  in 
fulfilling  their  requirements.  User  satisfaction  is  also  used  as 
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a  measure  of  system  effectiveness  since  greater  usage  is 


associated  with  greater  perceived  effectiveness  (15:145,13:83- 
86) .  Since  user  satisfaction  only  indicates  perceived 
effectiveness,  Sprague  and  Carlson  have  developed  more  detailed 
evaluation  criteria  for  DSS . 

Sprague  and  Carlson  group  DSS  evaluation  criteria  in  four 
areas : 

1.  Productivity  Measures:  Measure  of  the  impact  the 
DSS  has  on  decisions.  Examples  of  productivity  measures  include 
the  time  required  to  reach  a  decision,  the  cost  of  making  a 
decision,  and  the  cost  of  implementing  a  decision. 

2.  Process  Measures:  Measure  of  the  impact  the  DSS 
has  on  the  decision  process.  These  measures  include  the  number 
of  alternatives  examined,  the  amount  of  data  used,  the  time  spent 
in  each  phase  of  decision  making,  and  the  number  of  participants 
in  the  decision  process. 

3.  Perception  Measures:  Measure  of  the  impact  the  DSS 
has  on  the  decision  maker.  Perception  measures  include  the 
control  of  the  decision-making  process,  ease  of  use,  usefulness 
of  the  DSS,  and  the  decision  makers  conviction  that  the  decision 
is  correct. 

4.  Product  Measures:  Measure  of  the  technical  merits 
of  the  DSS.  Product  measures  include  the  system  response  time, 
system  availability,  operating  costs,  education/ training  costs, 
and  data  acquisition  costs  (5:158-160). 

DSS  Structure 


To  provide  the  necessary  flexibility  and  adaptability 


necessary  for  the  development  of  a  DSS  using  the  adaptive  design 


methodology,  a  modular  design  is  required.  Sprague  and  Carlson 
provide  such  a  framework  with  their  dialog  component,  data 
component,  and  model  component  structure. 

Dialog  Component.  However  the  DSS  is  used,  the  user  must 
communicate  with  the  computer  via  some  type  of  dialog.  The 
dialog  component  is  comprised  of  the  hardware  and  software  that 
provide  the  interface  between  the  user  and  the  DSS.  The  user  - 
system  interaction  implies  three  necessary  capabilities.  First, 
the  interaction  must  have  an  action  language.  The  action 
language  defines  what  the  user  can  do  to  communicate  with  the 
system.  The  action  language  may  be  made  up  of  inputs  from 
regular  keyboard,  function  keys,  touch  panels,  a  joy  stick,  a 
mouse,  or  voice  commands.  Second,  the  user  -  system  interaction 
involves  a  display  or  presentation  language.  The  display 
language  provides  what  the  user  actually  sees  and  may  include 
character  or  line  printers,  a  display  screen,  a  graphics 
capability,  a  color  monitor,  plotters,  or  a  voice  output.  Third, 
the  interaction  requires  a  knowledge  base  which  includes  what  the 
user  must  know  to  interact  with  the  DSS.  The  knowledge  base  may 
be  in  the  user's  head,  in  a  reference  manual,  or  provided  through 
help  commands.  Combinations  of  these  three  interaction 
capabilities  comprise  the  dialog  between  the  user  and  the  DSS 
(5:  198)  . 

The  manner  in  which  the  interaction  capabilities  are 
combined  produces  the  dialog  style.  The  effectiveness  of  a 
particular  style  depends  on  the  type  of  user,  the  task  to 
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perform,  and  the  general  decision  situation.  Following  are 
descriptions  of  several  types  of  dialog  styles: 

1.  Question/Answer  Dialogs:  This  style  consists  of  a 
question  and  answer  session  between  the  user  and  the  system.  It 
allows  the  system  to  lead  the  user  through  the  decision  process 
in  a  rather  structured  manner.  The  question/answer  dialog  style 
seems  to  be  most  effective  when  dealing  with  inexperienced  or 
infrequent  users  who  are  unfamiliar  with  the  problem  to  be 
solved.  This  style  is  least  successful  for  the  sophisticated  or 
frequent  users  (5:199). 

2.  Command  Language  Dialog:  The  command  language 
dialog  style  consists  of  a  formal  language.  This  style  has  the 
advantage  of  being  relatively  quick,  however,  the  casual  user 
will  probably  have  to  relearn  the  language  each  time  he  uses  the 
system  (5 : 200) . 

3.  Menu  Dialogs:  This  style  allows  the  user  to 
proceed  along  a  course  of  menus  as  he  proceeds  through  the 
decision  process.  The  menu  dialog  style  offers  the  advantages  of 
the  question/answer  dialog  style,  however,  it  still  allows  some 
flexibility  to  investigate  the  problem  as  the  user  sees  fit.  The 
menu  dialog  has  become  a  very  popular  style  for  DSSs 

(5:201  ; 2  ;  3 ; 4 )  . 

4.  Input  Form/Output  Form  Dialog:  This  type  of  dialog 
is  very  useful  for  entering,  displaying,  and  modifying  data  base 
information  (5:202). 


5.  Combination  Dialog:  As  its  name  implies,  the 


combination  dialog  contains  combinations  of  several  different 
dialog  styles.  The  use  of  the  combination  dialog  allows  the  DSS 


to  remain  flexible  and  effective  for  both  experienced  and 
inexperienced  users  (5:203). 

Data  Component.  The  data  component  supports  the  memory 
requirements  of  the  DSS .  The  data  component  encompasses  many  of 
the  intelligence  activities  from  Simon’s  model.  The  data 
component  must  meet  many  different  requirements.  Although  the 
requirements  for  every  specific  DSS  will  be  different,  the 
following  list  of  data  component  requirements  should  be 
considered : 

1.  Support  for  memory  aids  such  as  workspaces, 
intermediate  results,  notepads,  memory  joggers,  etc. 

2.  Data  reduction:  This  includes  subsetting, 
combining,  and  aggregating. 

3.  Support  varying  levels  of  data  detail. 

4.  Support  varying  amounts  of  data. 

5.  Support  multiple  sources  of  data:  data  external  to 
the  organization,  internal  data,  and  data  from  different  parts  of 
the  organization. 

6.  Support  a  catalog  of  data  sources:  This  provides 
the  user  with  the  ability  to  see  where  data  comes  from  and  what 
data  is  in  what  data  base. 

7.  Support  a  wide  time  frame  of  data:  Some  decisions 
require  data  projected  to  the  future  in  addition  to  historical 
data . 

8.  Support  data  security:  Some  data  may  not  be 
appropriate  for  the  entire  organization  to  access. 


9. 


Per  f  ormance : 


The  response  time  between  a  data 


query  from  the  user  and  fulfillment  of  the  request  must  be  quick 
enough  that  it  does  not  interrupt  the  users  decision  process. 

10.  Interface  to  the  other  components:  The  data 
component  must  interface  smoothly  with  the  other  two  components 
for  a  DSS  to  be  effective  (5:240;21). 

The  heart  of  the  data  component  is  the  data  base  management 
system  (DBMS).  *A  DBMS  is  a  collection  of  computer  programs  used 
to  create,  maintain,  access,  update,  and  protect  one  or  more  data 
bases*  (5:222).  Operations  provided  by  a  DBMS  include  (5:240): 

1 .  Create 

2.  Delete 

3.  Dictionary 

4 .  Update 

5.  Query/retrieval 

6.  Views/subsetting 

7.  Protection/security 

8.  Sharing 

9.  Recovery 

10.  Optimization 

There  are  several  different  approaches  in  implementing  a 
DBMS.  Among  the  most  popular  today  is  the  relational  data  base 
approach.  The  relational  approach  is  relatively  easy  to 
understand  and  provides  set  operations,  independence  of  data 
programs,  operation  and  integrity  constraints,  and  a  close 
coupling  between  the  data  base  and  the  data  dictionary  (5:226). 

Model  Component.  The  modeling  component  supports  Simon’s 
design  and  choice  activities.  The  model  component  contains  the 


operations  that  manipulate  the  representations.  As  stated 


previously,  these  operations  may  be  as  simple  as  a  set  of  command 
language  statements  that  can  be  sequenced  to  sophisticated 


forecasting  and  linear  programming  models.  The  model  component 
allows  the  user  to  analyze  the  problem  and  create  alternative 
solutions.  Sprague  and  Carlson  feel  the  integration  of  models 
into  an  information  system  moves  it  from  being  a  management 
information  system  to  a  decision  support  system  (5:259). 

General  design  and  choice  activities  the  model  component  may 
support  are:  projection,  deduction,  analysis,  creation  of 
alternatives  or  suggestions,  comparison  of  alternatives, 
optimization,  and  simulation.  The  model  component  should  allow 
examination  of  intermediate  results  and  accommodation  of 
subjective  judgment  during  the  problems  solving  process  (5:260). 

DSS  Generator 

Flexible  software  is  required  to  implement  the  DSS  component 
modules  and  to  support  the  continuous  system  changes  required  in 
adaptive  design  methodology.  Haul  and  Saxena  have  expanded 
Sprague  and  Carlson’s  suggestions  for  a  DSS  generator  structure. 


Kaul 

and 

Saxena  list  5  essential  components  of  a  general  DSS 

generator 

: 

1  . 

User  Interface  Manager 

2. 

Representation  Manager 

3. 

Analysis  Manager 

4  . 

Systems  Manager 

5. 

Data  Extraction  Manager 

A1 though 

all 

these  components  may  not  be  required  to  build  a 

specif ic 

DSS  , 

they  do  provide  the  general  capabilities  required 
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of  a  DSS  generator  (10:150). 


Peer  Interface  Manager.  The  User  Interface  Manager  provides 
the  software  support  to  develop  a  variety  of  dialog  styles.  The 
term  "User  Friendliness'  has  often  been  used  to  describe  a 
required  user  -  system  interface.  Unfortunately,  what  is  user 
friendly  for  one  decision  maker  may  not  be  user  friendly  to 
another.  Haul  and  Saxena  believe  the  dialog  style  used  to 
achieve  user  friendliness  is  a  function  of  training  or  experience 
and  how  much  the  decision  maker  uses  the  system.  As  can  be  seen 
from  Table  2.2,  to  achieve  maximum  system  flexibility  the  User 
Interface  Manager  should  have  the  capability  to  develop  three 
basic  dialog  types.  Additionally,  the  User  Interface  Manager 
should  have  the  capability  to  address  alpha-numeric  and  graphics 
displays,  printers,  and  plotters  (10:150). 


Table  2.2  Dialog  Styles 


Casual  User 

Regular  User 

Trained 

Menu 

Command  Language 

User 

Command  Language 

Untrained 

Natural  Language/ 

Menu 

User 

Question  &  Answer 

Representation  Manager.  The  Representation  Manager  supports 
the  representations  function  in  the  ROMC  requirements  definition 
approach.  The  Representation  Manager  should  provide  the 
capability  to  develop  and  save  a  variety  of  different  screen 


displays  such  as  pie  charts,  bar  graphs,  spreadsheets,  data  base 
entry  forms,  and  data  base  reports.  The  Representation  Manager 
should  also  have  the  capability  to  store  and  retrieve  command 
sequences  to  produce  a  particular  screen  representation  or 
printed  report  (10:151-152). 

Analysis  Manager.  The  Model  Manager  is  primarily  concerned 
with  supporting  the  model  component  of  the  DSS .  The  Model 
Manager  should  have  the  capability  to  develop  mathamatical 
modeling  and  command  procedures.  A  model  base  management 
capability  is  also  highly  desirable.  Model  base  management  is  a 
flexible  way  to  define,  save,  invoke,  and  delete  analyis  routines 
similiar  to  the  relationship  between  a  data  base  management 
system  and  the  data  base.  An  additional  requirement  of  the 
Analysis  Manager  is  data  manipulation  (10:153-154). 

System  Manager.  The  System  Manager  provides  support  to  the 
more  DSS-unique  and  advanced  requirements.  The  System  Manager 
3hould  provide  the  capability  to  accomodate  decisions  made  by 
groups  or  decisions  made  in  parts  by  several  different 
individuals  which  require  shared  data  and  model  bases.  The 
System  Manager  also  supports  the  control  mechanism  portion  of 
ROMC  by  providing  a  capability  to  define  function  and  control 
keys  and  develop  help  facilities.  The  more  advanced  capabilities 
of  the  System  Manager  include  providing  feedback  to  both  the  DSS 
user  and  builder.  This  feedback  may  be  in  the  form  of  recording 
the  frequency  of  command  usage,  response  times  to  operations, 
data  base  capacity,  and  user  errors.  Finally,  the  System  Manager 
should  be  able  to  record  system  problems  and  desired  changes 


(10: 155-156) . 


Pat*  Extraction  MtnKir.  The  data  extraction  manager  is 
concerned  with  the  capability  of  the  system  to  access  required 
external  data  bases  and  extract  the  required  data  (10:157). 

Expert  Systems 

Expert  Systems  (ES)  are  in  many  ways  similiar  to  Decision 
Support  Systems  (DSS) .  Both  ES  and  DSS  are  developed  to  improve 
decision-making,  however,  there  are  also  significant  differences 
between  the  two.  In  a  way,  DSSs  are  broader  than  ES .  As  such, 

ES  can  be  integrated  into  an  overall  DSS  --  possibly  as  part  of 
the  model  component. 

An  Expert  System  is  *a  problem  solving  program  that  achieves 
good  performance  in  a  specialized  domain  that  generally  requires 
specialized  knowledge  and  skill.  The  systems  process  the 
knowledge  of  experts  and  attempt  to  mimic  their  thinking,  skill, 
and  intuition'  (0:22).  Expert  Systems  generally  have  three  basic 
characteristics : 

1.  The  areas  of  knowledge  have  4  prerequisite 

qual i ties : 

a.  They  have  a  well-defined  domain  of  application 
and  are  sufficiently  constrained  to  make  successful  coding  of 
relevant  knowledge  likely. 

b.  There  is  at  least  one  expert  who  can  perform 

the  task  well. 

c.  The  expert  is  available  to  help  develop  the 
knowledge  base  which  contains  special  knowledge,  judgment,  and 


experience  factors. 
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d.  The  expert  can  clearly  describe  the  knowledge 
base  and  explain  the  methods  of  applying  it  to  the  task. 

2.  ES  employ  a  significant  amount  of  heuristic  problem 
solving  or  rule  of  thumb  techniques. 

3.  ES  use  three  different  general  kinds  of 
information : 


a.  Task  Specific:  data  relevant  to  the  current 

ES  analysis. 

b.  Domain  Specific:  the  knowledge  base  as 

described  above  and  including  problem  solving  rules. 

c.  Control:  the  inference  engine  which  applies 

axiomatic  knowledge  in  the  knowledge  base  to  the  task  specific 
data  in  order  to  arrive  at  possible  solutions  (8:23-25) . 

In  addition  to  those  characteristics  listed  many  ES  are  now 
being  developed  with  an  explanation  capability.  This  capability 
provides  the  logic  used  to  arrive  at  a  solution  (8:24; 17). 

Expert  Systems  and  Decision  Support  Systems  can  be  compared 
in  several  different  areas.  As  mentioned  above  the  basic  goal  of 

both  systems  is  to  improve  the  quality  of  decisions  the  systems 

\ 

support.  Although  the  basic  goals  of  the  two  systems  are  the 
same,  they  have  different  objectives.  Generally,  the  objective 
of  a  DSS  is  to  provide  the  decision  maker  with  a  data  and  model 
capability  to  be  used  as  the  decision  maker  desires  during  the 
decision  process.  The  general  objective  of  an  ES  is  to  provide 
the  decision  maker  a  conclusion  or  decision  that  is  correct  a 
high  percentage  of  the  time.  The  differences  in  objectives  leads 
to  differences  in  the  operational  utilization  of  the  two  systems. 
A  DSS  allows  the  user  to  confront  a  problem  in  a  flexible  way  by 
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Wanna: 


providing  the  ability  to  manipulate  data  and  models  in  a  variety 
of  ways  while  progressing  through  the  decision  process.  As  such 
a  DSS  user  exercises  direct  control  over  the  various  DSS 
components.  With  an  ES ,  the  user  retains  little  if  any 
flexibility  in  the  way  the  system  analyzes  the  problem.  In  other 
words  the  system  directs  the  user.  Both  systems  are  designed 
using  an  adaptive  design  type  of  approach  but  for  different 
reasons .  DSS  builders  generally  use  the  adaptive  design  approach 
to  allow  greater  user  involvement  in  the  design  process,  allow 
the  system  to  evolve  and  adapt  to  the  needs  of  the  user,  and  to 
provide  usable  decision  support  in  the  early  stages.  ES 
developers  use  adaptive  design  to  allow  the  knowledge  base  to  be 
refined  or  expanded.  Since  the  performance  of  an  ES  is  primarily 
dependent  on  the  completeness  and  quality  of  the  knowledge  base 
rather  than  the  reasoning  techniques,  the  system  must  be  built  up 
adaptively  or  in  stages  before  complex  problems  can  be  solved 
(8 : 22-26 ; 17 ; 21 ) . 

Chapter  III  discusses  the  application  of  the  adaptive  design 
methodology  to  the  problem  of  building  a  decision  aid  for  the 
6916ESS  scheduling  problem.  Chapter  IV  discusses  the  system  that 
resulted  from  applying  the  adaptive  design  methodology. 


Ill  APPLICATION  OF  ADAPTIVE  DESIGN 
TO  THE  69 16ESS  SCHEDULING  DECISION  AID 


Introduction 

Chapter  3  discusses  the  application  of  the  adaptive  design 
methodology  to  the  problem  of  building  a  decision  aid  for  the 
6916ESS.  The  first  action  in  the  adaptive  design  process  was  to 
select  a  decision  process  within  the  6916ESS  which  could  benefit 
from  a  computer-based  decision  aid.  Several  areas  within  the 
squadron  were  good  candidates.  However,  the  operations  aircrew 
scheduling  process  was  chosen.  From  experience,  the  scheduling 
decision  process  offered  the  greatest  potential  for  increased 
efficiency  and  effectiveness  by  saving  time  and  reducing 
scheduler  mistakes. 

When  developing  a  DSS ,  the  builder  will  normally  begin  by 
trying  to  define  the  decision  process.  This  action  was  not 
necessary  in  this  case  because  the  6916ESS’  scheduling  process 
is  already  well  defined  and  well  understood.  Although  defining 
the  actual  decision  process  was  not  necessary,  important 
functions  or  activities  within  the  decision  process  had  to  be 
identi f ied . 

Structuring  the  Decision  Process 

Identification  of  the  major  functions  and  activities  within 
the  scheduling  process  was  the  first  step  in  structuring  the 
decision  process.  The  major  scheduling  functions  and  activities 
were  identified  from  experience  and  through  correspondence  with 
the  69I6ESS  schedulers.  Once  the  functions  and  activities  were 
identified,  they  were  grouped  in  common  areas  and  displayed  a 
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line  diagram  format  similiar  to  an  organization  chart 
Figure  3.1  shows  the  organization  chart  for  the  major 
scheduling  functions  and  activities. 
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Figure  3.1  Main  Menu 
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The  Storyboarding  Process 

The  next  step  in  the  adaptive  design  process  was  to 
develop  storyboards  for  each  function  and  activity 
identified  in  the  feature  chart.  As  discussed  in  Chapter 
II,  Sprague  and  Carlson’s  Representations,  Operations, 

Memory  Aids,  and  Control  mechanisms  (ROMC)  are  an  effective 
approach  in  developing  storyboards.  Using  the  ROMC 
approach,  example  computer  screens  were  developed  to  portray 
what  the  scheduler  would  like  to  see  on  the  computer  screen 
and  have  available  to  him  when  performing  the  major 
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scheduling  functions  and  activities. 


The  s toryboard i ng 


process  started  by  developing  example  menu  selection 
screens.  The  connectivity  for  the  menu  structure  was  taken 
directly  from  the  organization  chart.  After  the  general 
organization  menus  were  completed,  sample  computer  screen 
'snapshots*  were  developed  for  the  specific  functions  and 
activities.  For  each  storyboard,  the  representations, 
operations,  memory  aids,  and  control  aids  to  assist  the  scheduler 
while  performing  an  activity  were  listed  for  each  sample  computer 
display.  Since  one  of  the  major  tenants  of  adaptive  design  is  to 
involve  the  user  as  much  as  possible,  a  copy  of  the  storyboards 
were  sent  to  the  0916ESS  schedulers  for  their  comments  and 
recommendations .  Due  to  the  distance  between  the  builder  and  the 
6910ESS,  the  US  mail  system  provided  the  only  option  for 
connectivity.  The  effectiveness  of  accomplishing  portions  of  the 
adaptive  design  process  remotely  is  discussed  in  Chapter  V. 
Storyboard  examples  developed  for  the  0916ESS  scheduling  decision 
process  can  be  found  in  Appendix  A. 

Results  of  the  Storyboardln*  Process.  The  storyboarding 
process  was  an  invaluable  exercise  in  building  the  6916ESS 
scheduling  decision  aid.  Storyboarding  helped  to  further 
identify  and  refine  the  major  scheduling  functions  and 
activities.  Use  of  the  ROMC  approach  and  associated 
identification  of  individual  representations  and  operations 
associated  with  each  activity,  permitted  a  more  detailed 
investigation  of  the  scheduling  process.  Specifically,  the 
storyboards  provided  a  clearer  view  of  the  interrelationships 
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between  different  scheduling  activities.  Identification  of  the 
memory  aids  that  would  be  needed  for  each  activity  was  a  major 
factor  in  developing  the  data  base  requirements.  Memory  aids 
also  established  a  requirement  for  a  capability  to  allow  the 
scheduler  to  make  notes  to  himself  while  performing  scheduling 
activities.  Identification  of  the  representations,  operations, 
and  control  aids  necessary  for  each  activity  also  helped  define 
the  dialog  style  best  suited  for  the  scheduling  decision  aid. 
Finally,  and  maybe  most  importantly,  the  storyboarding  process 
permitted  a  detailed  examination  of  the  functional  requirements 
for  the  scheduling  decision  aid.  In  other  words,  the 
storyboarding  process  identified  what  outputs  the  resulting 
system  should  contain  and  what  functions  were  necessary  to 
support  the  major  scheduling  decision  process  at  the  6916ESS.  A 
total  of  approximately  30  hours  were  spent  building  this  initial 
system  design. 

Since  the  storyboarding  process  helped  identify  the  major 
system  requirements,  the  next  step  was  to  begin  implementing  on 
the  computer  those  functions  and  activities  identified  through 
the  storyboarding  process  on  the  computer.  However,  before  the 
system  could  be  built,  a  software  package  supporting  the  major 
elements  of  the  decision  aid  design  process  had  to  be  selected. 

Software  Selection 

Software  selection  was  driven  by  what  was  available  for  the 
Zenith  Personal  Computers  at  AFIT  and  what  could  reasonably  be 
expected  to  be  available  at  the  Air  Force  squadron  level.  These 
constraints  narrowed  software  selection  to  dBASE  III,  Lotus 


1-2-3,  and  Enable.  dBASE  III  is  primarily  a  relational  data  base 
system  with  the  ability  to  develop  user  defined  menus.  Since  it 
is  primarily  a  data  base  system  it  does  not  offer  the  flexibility 
required  to  build  an  entire  decision  aid  or  decision  support 
system,  however,  it  could  function  as  the  data  base  component. 
Similarly,  Lotus  1-2-3  is  primarily  a  spreadsheet  system.  It 
could  function  as  tne  prime  system  for  the  model  base 
component.  Enable  is  an  integrated  wordprocessing, 
spreadsheet,  and  relational  data  base  management  system. 

Enable  offers  the  flexibility  needed  to  construct  a  decision 
aid  and  since  it  is  a  versatile  package,  problems  associated 
with  integrating  a  separate  spreadsheet,  data  base  management 
system,  and  wordprocessing  capability  are  minimized. 

When  Enable  was  compared  with  the  DSS  generator  requirements 
listed  in  Chapter  II,  it  did  quite  well.  Enable  provides  the 
capability  to  develop  different  dialog  styles  including 
application  specific  menus,  system  menus,  question  and 
answer,  and  a  command  language.  Enable  has  a  graphics  capability 
to  develop  pie  charts,  bar  charts,  and  line  graphs.  The 
spreadsheet  application  displays  a  spreadsheet  similiar  to  Lotus 
1-2-3  that  can  be  sized  to  meet  the  user's  needs.  The  data  base 
management  system  application  allows  the  user  to  develop  user 
defined  input  and  output  forms  or  to  take  advantage  of  the 
standard  system  forms.  Addi tional ly ,  Enable  allows  the  user  to 
have  up  to  eight  applications  or  windows  open  simultaneously 
(e.g.  4  spreadsheets,  2  data  bases,  and  2  word  processing  files) 
and  also  permits  the  user  to  size  each  window  individually.  The 
macro  coding  procedure  allows  the  user  to  develop  sophisticated 


models  within  the  spreadsheet  application.  Enable  has  an 
extensive  help  facility  which  can  be  supplemented  by  user  defined 
help  files.  It  also  allows  the  user  to  define  function  keys  and 
other  alpha-numeric  keys  to  perform  different  functions.  Enable 
does  not  support  some  of  the  more  sophisticated  DSS  generator 
features  such  as  recording  the  frequency  of  command  usage  or 
capturing  response  times  to  operations,  and  user  errors,  but 
these  features  were  not  essential  because  the  6916ESS  scheduling 
problem  is  relatively  well  defined  and  each  function  built  for 
the  system  is  important  to  the  scheduling  function.  The  more 
sophisticated  DSS  generator  features  would  be  more  important  for 
a  DSS  being  built  for  a  relatively  undefined  decision  process 
where  the  builder  was  not  certain  what  functions  would  be  the 
most  important  or  that  received  the  most  use. 

Enable  is  a  flexible  software  package  and  meets  most  of  the 
DSS  generator  requirements  required  to  build  the  6916ESS  decision 
aid.  Additionally,  Enable  is  available  at  AFIT.  Finally,  since 
Enable  is  provided  with  the  Air  Force  Zenith  Z-248  buy,  it  can 
reasonably  be  expected  to  be  provided  at  the  squadron  level. 

After  the  software  package  was  selected,  system  implementation 
began . 

Kernel  Selection 

Since  there  were  many  functions  and  activities  to  implement, 
where  should  the  builder  start?  The  subproblem  selected  as  the 
starting  point  is  referred  to  as  the  kernel.  Woolsey  suggests 
the  builder  should  choose  those  functions  which  are  the  most  time 
consuming  and  mundane  as  the  starting  point  for  implementing  a 


DSS  (22).  If  the  DSS  saves  the  user  time,  he  will  have  more  time 


to  spend  on  the  more  difficult  activities  which  require  his 
judgment  and  choice.  This  approach  seemed  well  suited  to 
the  6916ESS  scheduling  problems  since  one  of  the  objectives 
of  the  scheduling  decision  aid  is  to  save  the  scheduler 
time  . 

Two  activities  were  identified  which  fit  Woolsey’s  criteria 
of  time  consuming  and  mundane.  First,  the  name,  rank  and  social 
security  number  of  each  mission  crewmember  must  be  typed  on  the 
flight  order  forms.  Since  the  6916ESS  schedulers  were  still 
doing  this  with  a  typewriter,  it  takes  them  up  to  45  minutes  to 
type  the  flight  orders  with  no  mistakes.  Second  as  mentioned  in 
Chapter  I,  schedulers  must  keep  a  running  total  of  each 
operator's  30  and  90  day  flight  hour  totals.  Calculation  of 
flight  hours  may  take  a  scheduler  over  one  hour  after  mission 
completion.  Since  these  two  activities  are  time  consuming  and 
take  the  schedulers  attention  away  from  their  primary  purpose  of 
scheduling  operators  to  fly,  they  were  selected  as  the  place  to 
start  system  implementation. 

Implementation  of  the  Kernels 

In  order  to  implement  the  two  kernel  activities,  experience 
with  the  Enable  software  package  was  required.  Both  kernels 
required  the  use  of  several  Enable  applications  (i.e. 
wordprocessing,  spreadsheet,  and  data  base).  The  two  kernels 
were  implemented  using  the  storyboard  representations  of  these 
two  activities  and  through  experimentation  with  the  different 
Enable  applications  and  interfacing  between  applications.  The  end 


result  of  implementing  the  two  kernel  activities  was  Version  0  of 


the  6916ESS  scheduling  decision  aid. 

Data  Base  Definition 

As  mentioned  earlier,  the  storyboarding  process  helped 
identify  the  data  that  was  required  to  perform  the  various 
scheduling  functions  and  activities.  The  specific  data  base 
requirements  were  organized  into  data  relations.  Additionally, 
the  relationships  between  different  data  relations  were  also 
defined.  Since  the  data  base  is  perhaps  the  most  important 
component  of  the  scheduling  decision  aid,  proper  data  base 
definitions  were  very  important.  Due  to  the  importance  of  the 
data  base,  assistance  from  a  data  base  expert  was  requested  to 
efficiently  define  the  data  structures.  Inefficient  data  base 
design  produces  unnecessary  duplication  of  data  and 
inefficiencies  in  data  retrival .  As  a  result,  system  response 
time  suffers  and  computer  disc  storage  space  becomes  constrained. 

To  develop  most  of  the  scheduling  functions  and  activities, 
example  data  was  required.  As  a  result,  sample  data  was  put  into 
the  data  base.  The  validity  of  the  data  is  based  on  experience 
and  the  percentages  of  the  different  type  of  operators  and  their 
qualifications  as  presented  in  chapter  I. 

System  Expansion 

After  the  kernel  activities  were  implemented,  the  system  was 
expanded  one  function  at  a  time  starting  with  the  process  of 
building  the  mission  flight  crew  and  ending  with  the  activities 
not  directly  associated  with  scheduling  operators  to  fly  a 
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particular  mission.  After  each  function  and  activity  was 
implemented  it  was  tested  under  a  variety  of  conditions  to  insure 
proper  output.  The  test  conditions  were  developed  in  advance  of 
testing  and  were  designed  to  portray  a  typical  mission  crew. 

When  problems  were  identified,  they  were  fixed  when  possible 
before  starting  the  next  activity.  The  system  expansion  process 
resulted  in  Version  1  the  of  6916ESS  scheduling  decision  aid. 
Version  1  will  be  discussed  in  detail  in  Chapter  IV. 


System  Evaluation 

When  Version  1  was  nearing  completion,  the  system  was 
evaluated  by  a  pseudo-scheduling  expert  from  HQ  ESC.  Since  it 
was  not  practical  to  get  a  scheduler  from  the  6916ESS  to  come  and 
evaluate  the  decision  aid,  a  former  Operation  Superintendent  at 
the  6916ESS  evaluated  the  decision  aid.  Suggestions  made  by  the 
evaluator  were  implemented  where  possible. 


Future  System  Modifications 

Throughout  the  entire  system  design  and  implementation 
process,  capabilities  which  were  not  implemented  in  Version  0  or 
Version  1  were  documented  for  future  implementation.  These  additional 
capabilities  will  be  discussed  in  Chapter  V. 

Chapter  IV  discusses  the  decision  aid  resulting  from  the 
adaptive  design  process.  The  resulting  system  will  be  described 
in  terms  of  Sprague  and  Carlson's  DSS  structure  (i.e.  dialog, 
data  base,  and  model  ba3e)  and  the  decision  aid's  menu  structure. 
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IV  0910ESS  SCHEDULING  DECISION  AID 

Introduction 

This  chapter  discusses  the  system  resulting  from  the  design 
process  discussed  in  Chapter  III.  The  organization  and  structure 
of  the  decision  aid  which  evolved  from  the  storyboarding  process 
closely  parallels  the  original  feature  chart  and  the  storyboards. 
Although  the  organization  of  the  scheduling  functions  and 
activities  changed  slightly,  the  actual  functions  and  activities 
remained  basically  the  same.  The  organization  of  the  6916ESS 
scheduling  decision  aid  is  structured  through  the  use  of  a  multi¬ 
level  menu  system,  with  the  main  menu  defining  the  major 
functions  of  the  system.  Additionally,  extensive  use  was  made  of 
Enable's  windowing  capability  to  provide  several  different  pieces 
of  information  to  the  scheduler  simultaneously.  Before 
providing  a  general  description  of  the  decision  aid’s  functions, 
the  decision  aid’s  components  (dialogue,  model  base,  and  data 
base)  are  discussed.  The  actual  computer  code  (macros) 
developed  for  the  system  serves  as  a  program  maintenance  manual 
and  is  located  in  Appendix  C.  A  User’s  Guide  is  located  in 
Appendix  B. 

System  Components 

As  presented  in  Chapter  II,  the  three  components  of  a 
Decision  Support  System  as  described  by  Sprague  and  Carlson  are 
the  dialog,  model  base,  and  the  data  base.  These  components 
provide  the  overall  structure  for  the  6916ESS  aircrew  scheduling 


decision  aid. 


most  important  component  in  the  scheduling  decision  aid  because 


the  6916ESS  aircrew  scheduling  process  is  data  intensive.  The 
data  base  is  composed  of  six  data  relations  shown  below  in  Figure 
4.1. 


Figure  4.1  Data  Base  Relations 


OPERATOR .  The  OPERATOR  relation  contains  general 
information  about  each  operator  as  described  in  Table  4.1. 


SSAN  Operator’s  Social 

Security  Number 


LASTNAME  Operator's  Last 

Name 


FIRSTNAME  Operator’s  First 

Name 


Used  as  a  unique  iden¬ 
tification  number  which 
allows  integration  of 
several  relations 

Used  by  the  scheduler  as 
the  primary  means  of 
identifying  an  operator 

Used  in  conjunction  with 
an  operator’s  last  name 


Operator's  Middle  Used  in  conjunction  with 

Initial  first  and  last  names 


RANK 

Operator's  Rank 

Used  for  Flight  Orders 
and  crew  balance 

TYPE 

Operator’s  General 

Type 

Used  for  general  data 
base  searches  for  squa¬ 
dron  management 

CREW 

Operator ’ s  Work  Crew 
(Able,  Baker,  Charlie, 
Days ) 

Used  for  data  base  sear¬ 
ches  to  identify  opera¬ 
tors  for  a  mission 

THIRTY 

Number  of  Flight  Hours 
an  Operator  has  over 
the  past  30  days 

Used  to  insure  an  opera- 
does  not  exceed  AF 
limits  for  30  day  hours 

NINETY 

Number  of  Flight  Hours 
an  Operator  has  over 
the  past  90  days 

Same  as  THIRTY  except 
for  90  consecutive  days 
instead  of  30 

SV83 

Date  Operator  last 
attended  SV-83  training 

Used  to  schedule  opera¬ 
tors  for  SV-83  training 

LIFESPT 

Date  Operator  last 
attended  Life  Support 
Training 

Used  to  schedule  opera¬ 
tors  for  semi-annual 
life  support  training 

PHYSIO 

Date  Operator  last 
attended  Physiological 
Training 

Used  to  schedule  opera¬ 
tors  for  recurring 
physiological  training 

FLTPHYS 

Date  Operator  last  had 
a  Flight  Physical 

Used  to  monitor  compli- 
with  annual  flight 
physical  requirement 
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The  information  contained  in  the  OPERATOR  relation  is  used 
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by  several  other  relations  as  shown  in  Figure  4.2. 
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Figure  4.2  Relation  Integration 


POSITION ■  The  POSITION  relation  is  the  primary 
relation  used  for  data  base  searches.  This  relation  contains  information 
concerning  the  position  qualifications  each  operator  possesses. 

Specific  fields  are  described  in  Table  4.2. 


Table  4.2  POSITION. DBF  Relation 


Field  Name _ Description 

SSAN  Operator’s  Social 

Security  Number 


POSITION  Position  Designation 


Purpose _ 

Unique  identifier  which 
allows  access  to  other 
relations 

Desgnation  for  each  posi¬ 
tion  an  op  is  qualified 
for  or  is  in  training  for 


PRIMARY 

QUAL 

TRAINER 

EVAL 

EXPLEVEL 


TRNGQUE 


STRENGTH 


Yes/No  field 

Position  Qualification 
Level 

Yes/No  field 

Evaluation  Date 

Experience  Designation 

Training  Priority 

Strength  as  a  Trainer 


Flag  for  an  op’s  primary 
position 

Designator  for  the  qual¬ 
ification  level  an  op  has 
reached  for  a  position 

Flag  to  designate  if  an 
op  is  a  qualified  trainer 

Date  an  op  is  due  an  eval¬ 
uation  for  a  position 

Subjective  measurement  of 
an  op’s  experience  in  a 
position  --  Assigned  by 
squadron  management  -- 
Defined  for  future  model 
applications 

Subjective  priority  given 
to  trainees  --  Assigned  by 
squadron  management. 

Used  to  help  match 
trainees  with  trainers 


WEAKNESS 


Weakness  as  a  Trainee  Used  to  help  match 

trainees  with  trainers 


The  following  fields  access  information  from  the  OPERATOR 
relation:  (see  Table  4.1) 

LASTNAME,  FIRSTNAME,  MI,  RANK,  CREW,  THIRTY,  AND.  NINETY 

The  following  fields  access  information  from  the  ABSENT 
relation:  (see  Table  4.3) 


START,  STOP,  AND  REASON 


: 
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The  POSITION  relation  draws  upon  the  OPERATOR  relation  for 
an  operator's  name,  crew,  rank,  and  30  and  90  day  flight  hours. 
This  relation  also  draws  upon  the  ABSENT  relation  for  operator 
availability  data.  The  POSITION,  OPERATOR,  and  ABSENT  relations 
are  interfaced  with  each  other  through  the  use  of  the  operator's 
social  security  number  as  shown  in  Figure  4.2. 

ABSENT .  The  ABSENT  relation  contains  information 
concerning  an  operator’s  availability  to  fly.  Specific  fields 
are  described  in  Table  4.3. 

Table  4.3  ABSENT. DBF  Relation 


Field  Name 

Description 

Purpose 

SSAN 

Operator's  Social 

Number 

Allows  scheduler  to  link 
to  other  data  relations 

START 

Date  Operator  becomes 
Unavailable 

Used  during  searches  for 
available  operators 

STOP 

Date  Operator  becomes 
Available 

Used  during  searches  for 
available  operators 

REASON 

Reason  Operator  is 
Unavai labl e 

Used  to  answer  queries 
why  an  operator  is 

unavai lable 

The  following  field  names  access  data  from  the  OPERATOR 
relation:  (see  Table  4.1) 

LASTNAME,  FIRSTNAME 

OPHISTY-  The  OPHISTY  relation  contains  each 
operator's  flight  history,  similiar  to  the  flight  cards  currently 
manually  maintained  by  the  schedulers.  Specific  fields  for  this 


relation  are  described  in  Table  4.4. 
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Table  4.4  OPHI STY . DBF  Relation 


Field  Name 

Description 

Purpose 

SSAN 

Operator's  Social 
Security  Number 

Used  to  access  information 
from  other  data  relations 

MISSION 

Mission  Number 
Designation 

Used  to  access  information 
from  another  relation 

DURATION 

Mission  Duration 
in  hours 

Used  to  calculate  30/90 
day  flight  hours 

POSITION 

Position  Designator 

Used  to  designate  which 
position  op  flew 

DATE 

Mission  Date 

Used  to  when  calculating 
30/90  day  flight  hours 

The  following  field  names  access  information  from  the 
OPERATOR  relation:  (see  Table  4.1) 

LASTNAME,  FIRSTNAME 

MSNHISTY.  The  MSNHISTY  relation  contains  the 
general  mission  history  for  the  squadron.  Specific  fields  for 
this  relation  are  described  in  Table  4.5. 

The  MSNHISTY  data  relation  is  not  critical  to  the  scheduling 
decision  aid.  However,  it  will  be  very  important  if  the  decision 
aid  is  expanded  to  include  other  squadron  decision  processes  such 
as  collection  management.  Further  discussion  of  system  expansion 
is  given  in  Chapter  V. 

MISSION.  The  MISSION  relation  contains 
information  on  the  projected  mission.  Specific  fields  are 

4 

described  in  Figure  4.6. 
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Table  4.5  MSNHI STY . DBF  Relation 


1 

I 

I 

Field  Marne _ Description 

MISSION  Mission  Number 

Designator 

DATE  Mission  Date 

TAKEOFF  Take  Off  Time 


LAND 


Land  Time 


DURATION 

Mission 

Duration 

ORBITTIME 

Mission 

Orbit 

Time 

WATCHTIME 

Mission 

Watch 

Time 

STATUS 

Mission 

Status 

REMARKS 

Mission 

Remarks 

_ Purpose _ 

Unique  identifier  for  each 
mission 

Date  mission  was  flown 

Take  off  time  helps  deter¬ 
mine  mission  duration 

Land  time  helps  determine 
mission  duration 

Used  when  determining 
total  hours  flown  by  the 
squadron 

Total  time  on  orbit  helps 
determine  mission 
e  f  f  ect i veness 

Total  watch  time  helps 
determine  mission 
ef  f  ecti veness 

Determined  by  planned  vs 
actual  orbit  time  --  a 
measure  of  effectiveness 

Used  to  add  general 
remarks  about  a  mission 

Used  to  highlight  missions 
that  required  special 
attention  when  scheduling 
the  mission  crew 


PRIORITY 


Mission  Priority 


Field  Name 


TYPE 


NUMBER 


TAKEOFF 


LAND 


DATE 


SHOWTIME 


PRIORITY 


DURATION 


Table  4.6  MISSION. DBF  Relation 


Description 


Mission  Type 


Mission  Number 


Take  Off  Time 


Land  Time 


Mission  Date 


Pre-mission  Show  Time 


Mission  Priority 


Mission  Duration 


Purpose 


Determines  position  con- 
f i gurat i on 

Unique  identification 
for  each  mission 

Scheduled  takeoff  time 
helps  determine  crewrest 
violations 

Scheduled  land  time  helps 
determine  crewrest 
violations 

Scheduled  mission  date 
determines  which  crew  is 
responsible  for  mission 
manning 

Scheduled  crew  showtime 
determined  by  scheduled 
takeoff  time 

Designator  for  missions 
that  require  special 
attention  when  schedul¬ 
ing  crewmembers 

Scheduled  mission  duration 
determined  by  scheduled 
takeoff  and  land  times 


Dialog  Component.  The  dialog  component  of  the  6916ESS 
aircrew  scheduling  decision  aid  is  composed  of  several  different 
dialog  types.  System  unique  menus  assist  the  user  in  moving  from 
one  scheduling  function  to  another  and  also  within  a  specific 
function.  A  question  and  answer  dialog  style  is  used  when  the 
system  needs  information  in  order  to  carry  out  an  operation. 
One-stroke  function  keys  are  defined  to  allow  the  user  to  quickly 


and  easily  accomplish  repetitive  operations.  Finally,  the  user 
can  also  use  the  generic  Enable  menu  system  for  general 
operations  like  browsing  through  the  data  base. 

Model  Base  Component.  The  model  base  does  not  contain  any 
sophisticated  analytical  techniques.  Instead,  the  model  base 
contains  the  macro  codes  necessary  to  allow  the  system  to  model 
the  6916ESS  aircrew  scheduling  decision  process  as  much  as 
possible.  Traditional  analytical  techniques  and  other  models 
could  be  integrated  into  the  6916ESS  aircrew  scheduling  decision 
aid  and  could  probably  benefit  the  6916ESS  schedulers.  Further 
discussion  on  this  subject  is  contained  in  Chapter  V. 


Main  Menu 

The  main  menu  developed  for  the  6916ESS  scheduling  decision 
eid  is  depicted  in  Figure  4.3.  The  main  menu  is  automatically 
displayed  for  the  user  after  the  system  logo.  The  main  menu 
provides  the  scheduler  a  choice  of  the  main  functions  he  is 
responsible  for.  The  remainder  of  this  chapter  will  be  devoted 
to  provi ling  a  general  description  of  the  major  scheduling 


functions  implemented 


the  kernel  6916ESS  decision 


MAIN  MENU 

SELECT  ONE: 

BUILD  FLIGHT  CREW 

MISSION  SCHEDULE 

OPERATOR  INFORMATION 

UPDATE  OPERATOR  INFORMATION 

1=  MISSION  COMPLETION  ACTIONS 

2=  MISCELLANEOUS 

FLIGHT  ORDERS 


aid  . 


The  build  flight  crew  function  is  the  heart  of  the  6916ESS 
aircrew  scheduling  decision  aid.  More  than  any  other  function  in 
the  decision  aid,  the  build  flight  crew  function  provides  the 
scheduler  with  the  opportunity  to  exercise  his  judgment  and 
choice  while  building  a  mission  flight  crew.  Essentially,  this 
function  provides  a  tailored  list  (based  on  duty  crew)  of 
available  operators  qualified  to  fly  a  specific  position  chosen 
by  the  scheduler.  The  list  of  available  operators  includes  a 
list  of  default  operator  characteristics:  position 
qualifications,  how  much  they  have  flown  in  the  past  30  and  90 
days,  trainer  or  trainee  qualifications,  strengths  as  a  trainer, 
which  work  crew  they  are  assigned  to,  and  training  queue 
priority.  This  default  list  may  be  easily  changed  if  the 
scheduler  desires  other  information  when  making  a  scheduling 
decision.  Once  a  scheduler  has  selected  an  operator  to  fly  a 
particular  position,  all  necessary  information  about  that 
operator  is  automatically  extracted  from  the  data  base  and 
transferred  to  a  spreadsheet  where  the  mission  crew  is  compiled. 

The  mission  crew  spreadsheet  is  developed  from  a  profile 
spreadsheet  shell.  The  profile  shell  provides  space  for  each 
operator  type  that  is  required  for  each  different  mission  type. 
Additionally,  the  total  number  of  operators  and  the  total  number 
of  crewmembers  (operators,  observers,  and  maintenance 
technicians)  already  scheduled  are  automatically  calculated  and 
provided  in  the  mission  crew  spreadsheet.  This  feature  will  help 
the  scheduler  determine  how  many  seats  are  still  open  for  the 
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Mission  Schaduls 

The  mission  schedule  function  is  designed  to  allow  the 
scheduler  to  input,  change,  delete,  and  display  information  about 
future  missions.  These  actions  are  accomplished  through  the 
Enable  add,  edit,  delete,  and  display  data  base  functions.  A 
data  input  form  was  built  to  assist  the  scheduler  when  adding 
mission  data  to  the  data  base. 

Operator  Information 

The  operator  information  function  allows  the  scheduler  to 
search  the  POSITION  relation  and  display  the  specific  information 
he  desires.  The  scheduler  must  become  familiar  with  the  Enable 
language  to  request  specific  information  or  a  specific  subset  of 
a  relation. 

Update  Operator  Information 

Selection  of  the  update  operator  information  function  allows 
the  scheduler  to  add,  change,  or  delete  information  in  the 
OPERATOR,  POSITION,  or  AVAIL  relations.  This  function  asks  the 
scheduler  what  information  he  would  like  to  update  and  then  opens 
the  appropriate  relation. 

Mission  Completion  Actions 

As  discussed  in  Chapter  I  ,  there  are  several  actions  the 
scheduler  must  accomplish  after  a  mission  is  completed.  These 
actions  are  displayed  in  a  submenu  if  the  'mission  completion 
actions  function*  is  selected  from  the  main  menu.  This 


submenu  is  depicted  in  Figure  4.4. 
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MISSION  COMPLETION  MENU 


UPDATE  MISSION  HISTORY  DATA  BASE 
1 =UPDATE  OPERATOR  FLIGHT  HISTORY  DATA  BASE 
2=UPDATE  30/90  DAY  FLIGHT  HOUR  TOTALS 
30  DAY  UPDATE 
90  DAY  UPDATE 

ADD  INDIVIDUAL  HOURS  (E-3A,  C-130,  ETC.) 
RETURN  TO  MAIN  MENU 


Figure  4.2  Mission  Completion  Menu 


The  update  mission  history  data  base  activity  involves 


updating  the  MSNHISTY  relation.  The  system  takes  the  scheduler 


directly  to  the  MSNHISTY  relation  and  displays  an  input  form 


which  requests  required  data  from  the  scheduler. 


The  update  operator  flight  history  data  base  activity 


updates  the  OPHISTY  relation.  The  system  will  prompt  the 


scheduler  for  the  mission  number  of  the  completed  mission.  The 


system  will  prompt  the  scheduler  for  required  information.  The 


majority  of  the  information  required  for  the  relation  update  is 


taken  from  the  mission  crew  spreadsheet.  Other  than  the  few 


prompts  the  system  makes  for  required  information,  the  relation 


update  is  done  automatically  by  the  system. 


The  update  30/90  day  hours  activity  updates  the  30  and  90 


day  flight  hour  fields  in  the  OPERATOR  relation.  The  system 


prompts  the  scheduler  for  the  30  and  90  day  windows  and  then 


automatically  extracts  the  proper  data  from  the  OPHISTY  relation 


This  data  is  then  transferred  to  a  spreadsheet  where  the  30  and 
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90  day  flight  hours  are  calculated  for  each  operator.  Once  the 


hours  have  been  calculated,  the  OPERATOR  relation  is  updated  from 


the  spreadsheet.  Except  for  providing  the  30  and  90  day  windows 


to  the  system,  this  entire  process  is  transparent  to  the 


scheduler.  Extensive  testing  has  verified  this  function  works  as 


expected . 


The  'add  individual  hours"  activity  was  added  to  the  system 


because  many  6916ESS  operators  occasionally  fly  with  other 


units  and  on  different  types  of  aircraft.  As  a  result,  a 


capability  was  required  to  allow  the  scheduler  to  update 


the  data  base  with  these  individual  hours. 


Flight  Orders 


The  flight  orders  function  was  designed  to  automatically 


format  and  then  print  the  flight  orders  for  the  scheduler  once 


the  mission  crew  was  finalized.  The  system  takes  information 


from  the  mission  crew  spreadsheet  (mission  number,  mission  date 


name,  social  security  number,  and  rank)  and  prompts  the  scheduler 


for  other  information  required  for  the  flight  orders.  The 


information  is  put  in  the  proper  format  in  a  word  processing  file 


ready  for  printing  whenever  the  scheduler  desires. 


Miscellaneous  Activities 


The  miscellaneous  activities  function  helps  the  scheduler 


keep  track  of  required  recurring  training  as  explained  in 


Chapter  I  (SV-83,  Life  Support,  Physiological,  and  Flight 


Physicals)  . 


Two  capabilities  were  built  into  the  system  that  do  not  come 


under  any  specific  heading.  First,  the  system  has  a  "notepad" 
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capability  that  the  scheduler  can  use  to  make  notes  to  himself. 

This  will  help  the  schedulers  to  remember  information  and  not  disrupt 
the  scheduling  process  to  any  large  extent.  Second,  a  rotating 
shift  schedule  was  developed  inside  a  spreadsheet.  The  shift 
schedule  is  a  memory  jogger  for  the  scheduler  to  keep  track  of 
which  crew  is  working  which  shift  on  a  given  day. 

Although  the  6916ESS  aircrew  scheduling  decision  aid  in  its 
current  form  meets  many  of  the  requirements  of  the  scheduling 
decision  process,  the  decision  aid  could  be  improved.  Chapter  V 
discusses  recommended  improvements  and  expansions  for  the  system. 
Additionally,  Chapter  V  discusses  recommendations  and 
conclusions  concerning  the  application  of  the  adaptive 
design  methodology  to  the  6916ESS  aircrew  scheduling 
decision  aid  design  and  implementation  process. 
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V  RECOMMENDATIONS  AND  CONCLUSIONS 

Introduction 

This  chapter  discusses  recommendations  and  conclusions  in 
two  areas.  First,  recommended  improvements  or  additions  to  the 
specific  0916ESS  scheduling  decision  aid  are  discussed.  Second, 
recommendations  and  conclusions  concerning  the  adaptive  design 
methodology  as  applied  to  building  the  0918ESS  decision  aid  are 
reviewed . 

0010ESS  Scheduling  Decision  Aid  Enhancement 

Recommended  changes  and  additions  for  the  6916ESS  scheduling 

decision  aid  were  documented  throughout  the  design  and 

implementation  phases  by  using  a  *hook  book.'  A  ’hook  book"  is  a 

collection  of  ideas  for  system  enhancement  that  formulate  during 

the  adaptive  design  process  but  which  are  not  implemented  due  to 

time  constraints,  technological  barriers,  cost,  and/or  the 

concept  of  adaptive  design  which  suggests  rapid  implementation 

and  evolution.  Since  one  of  the  precepts  of  the  adaptive  design 

process  is  an  evolving  system,  there  must  be  a  process 

established  to  capture  the  direction  and  ideas  for  system 

enhancement  and  expansion.  The  'hook  book’  concept  meets  this 

need.  A  'hook  book"  can  be  implemented  in  many  different  ways  -- 
from  a  formal  process  to  an  informal  process.  A  formal  process 
might  involve  having  the  builder  and  user  meet  at  set  intervals 

to  discuss  proposed  changes  to  the  system  which  the  user  has 

formally  documented.  An  informal  ’hook  book'  process  might 

involve  the  user  jotting  down  notes  about  the  system  on  scratch 

paper  or  in  a  system  word  processing  file.  The  builder  of  this 

decision  aid  kept  his  'hook  book'  in  a  notebook  with  other  system 
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documentation.  The  6916ESS  scheduling  decision  aid  provides  the 
schedulers  the  opportunity  to  keep  the  system  with  the  'notebook 
capability  provided  in  the  system. 

The  'hook  book"  items  or  system  enhancements  discussed  here 
are  not  in  priority  order  because  they  were  not  discussed  with 
the  user.  However,  if  the  6916ESS  scheduling  decision  aid  had 
been  built  in  the  field,  the  'hook  book'  items  would  be 
aggregated  and  then  prioritized  by  the  system  referee.  The 
system  referee  is  the  official  responsible  for  resolving 
conflicts  concerning  system  usage  and  system  changes. 

Overall  System  Expansion.  The  6916ESS  scheduling  decision 
aid  has  a  high  potential  for  system  expansion.  Since  several 
sections  within  the  Operations  Branch  use  common  data  on  mission 
performance  and  operator  attributes,  the  data  base  was  built  to 
allow  for  expansion  to  other  sections. 

The  Collection  Management  Section  is  responsible  for 
maintaining  and  analyzing  mission  statistics.  As  a  result,  they 
require  data  on  mission  types,  duration,  watch  time,  orbit  time, 
status,  remarks,  collection  time,  and  type  of  collection.  This 
mission  data  is  used  to  determine  mission  effectiveness  and  to 
explore  ways  to  increase  that  effectiveness.  Some  of  this  data 
is  already  contained  in  the  data  base  (see  Chapter  IV) .  The 
current  data  base  could  be  easily  expanded  to  include  all  the 
data  required  by  the  Collection  Management  Section. 

The  Training  Section  personnel  are  responsible  for 
monitoring  all  training  in  the  Operations  Branch.  As  such,  they 
require  data  on  each  trainee's  status  and  which  instructors  they 


have  flown  with.  This  information  is  used  to  provide 
recommendations  to  the  Operations  Officer  and  the  Chief  of 
Operations  Production.  Much  of  this  data  can  be  obtained  from 
the  current  data  base  with  the  proper  data  base  queries. 

The  Standardization  and  Evaluation  (Stan/Eval)  Section  is 
responsible  for  conducting  the  Operations  Branch  evaluation 
program.  This  section  must  keep  track  of  when  evaluations  are 
due  and  schedule  evaluators  to  conduct  evaluations.  There  is 
already  a  field  in  the  data  base  for  evaluation  due  dates  for  use 
by  both  the  schedulers  and  the  Stan/Eval  section  and  could  be 
used  as  an  automatic  suspense  file. 

A  networked  system  would  allow  all  sections  to  share  a 
common  data  base.  This  would  require  a  strong  data  base 
management  system  which  would  include  a  data  manager.  The  data 
manager  is  responsible  for  maintaining  the  integrity  of  the  data 
base.  As  such,  the  data  manager  would  develop  procedures 
to  ensure  only  specifically  identified  individuals  or  sections 
are  allowed  to  change  data  in  the  data  base.  This  type  of  system 
would  also  require  a  strong  model  base  management  system  similiar 
to  the  data  base  management  system  to  ensure  only  those 
authorized  could  modify  menus,  macro  procedures,  and  other  system 
mode  1 s . 

Model  Base.  The  model  base  could  be  enhanced  in  several 
ways.  The  6916ESS  schedulers  are  frequently  asked  to  project  the 
status  of  the  squadron's  mission  capabilities  in  the  future  so 
that  squadron  management  can  make  planning  decisions.  For 
example,  if  part  of  the  squadron  is  tasked  to  deploy  and  they 
must  also  continue  home  station  operations,  squadron  management 


will  want  to  know  how  long  they  will  be  able  to  continue  home 
station  operations  before  operators  start  exceeding  the  30  and  90 
day  flight  hour  limits.  Or,  if  the  squadron  is  faced  with  a  glut 
of  trainees  and  a  large  projected  departure  of  experienced 
operators,  squadron  management  will  want  to  know  what 
capabilities  they  will  have  when  the  departures  are  the  greatest. 
Finally,  during  times  of  crises,  the  6916ESS  may  be  tasked  to  fly 
more  often  and  for  more  hours.  In  this  case,  squadron  management 
will  want  to  know  how  long  they  will  be  able  to  maintain  expanded 
operations  before  training  and  administrative  paperwork  are 
significantly  degraded.  These  questions  could  be  analyzed 
through  implementation  of  forecasting  and  simulation  models  in 
the  decision  aid’s  model  base.  The  data  structures  required  for 
these  models  already  exist  in  the  data  base.  However,  a 
significant  effort  would  be  required  to  interface  the  models  with 
the  data  base. 

Presently,  the  decision  aid  helps  the  scheduler  build  and 
change  mission  flight  crews  by  providing  the  scneduler  with  a 
list  of  operators  available  to  fly  and  the  operator’s  attributes. 
It  is  up  to  the  scheduler  to  use  his  judgment  when  comparing  the 
operator’s  attributes  to  determine  which  operators  are  selected 
to  fly.  An  expert  system  could  be  designed  to  capture  the 
scheduler’s  judgment  and  heuristic  rules  used  when  selecting  one 
operator  over  another.  The  expert  system  could  be  integrated 
into  the  model  base  and  designed  to  access  the  data  base.  Since 
the  expert  system  would  be  built  using  the  schedulers  own 
judgmental  rules  and  heuristics,  it  could  further  help  the 


scheduler  produce  more  efficient  and  effective  mission  flight 
crew  schedules  by  saving  time  and  not  making  mistakes. 

Miscellaneous.  Since  many  operators  fly  more  than  one 
mission  in  a  row  (i.e.  fly  on  two  consecutive  days) ,  a  slip  in 
take  off  time  or  an  extension  of  mission  duration  may  mean  the 
operator  cannot  fly  the  next  day's  mission  due  to  crew  rest 
limitations.  The  system  should  have  the  capability  to  highlight 
those  operators  scheduled  to  fly  on  consecutive  days.  This 
capability  would  help  the  schedulers  to  quickly  identify  those 
operators  who  need  to  be  replaced  and  quickly  provide  potential 
replacements.  This  capability  could  be  provided  by  developing  a 
macro  procedure  to  search  the  next  day's  mission  spreadsheet  for 
the  operator  in  question. 


Recommendations  for  HQ  Electronic  Security  Command. 


HQ  ESC  should  consider  fielding  the  6916ESS  scheduling 
decision  aid.  The  6916ESS  could  act  as  a  test  location  to  see  if 
the  system  is  effective  in  the  field.  If  the  scheduling  decision 
aid  proves  to  be  successful,  HQ  ESC  should  plan  to  field 
similiar  systems  to  the  other  ESC  airborne  units.  During  the 
test  and  evaluation  at  the  6916ESS,  the  system  will  probably 
evolve  to  be  even  more  specific  to  the  6916ESS.  As  a  result,  HQ 


ESC  would  also  have  to  decide  what  version  of  the  6916ESS 


scheduling  decision  aid  to  implement  since  each  airborne  unit 
has  different  types  of  operators  and  slightly  different  missions. 
HQ  “ESC  should  also  consider  the  feasibility  of  implementing 
similiar  systems  at  the  6911ESS  and  the  6903ESS  who  have  missions 
similiar  to  the  ESC  airborne  units. 


The  ENABLE  software  package  proved  to  be  effective  and 
flexible  when  building  the  6916ESS  decision  aid.  The  cost  to  the 
government  of  the  ENABLE  software  package  is  inexpensive 
(approximately  $80).  Because  of  its  integrated  word  processing, 
spreadsheet,  and  data  base  capabilities,  many  applications  at  the 
squadron,  wing,  and  MAJCOM  could  be  implemented  using  the  ENABLE 
or  sirailiar  software  capability.  As  a  result,  HQ  ESC  should 
consider  providing  ENABLE  or  a  similiar  software  capability  to 
each  of  its  squadrons  and  wings. 

To  ensure  effective  and  efficient  performance  of  programs 
implemented  with  ENABLE,  the  personal  computers  used  should  have 
10  to  20  megabytes  of  hard  drive  disk  apace.  This  will  ensure 
the  programs  run  faster  and  the  user  does  not  have  to  bother 
changing  floppy  disks  during  execution.  Also,  many  applications 
may  require  more  disk  space  than  available  on  one  360  kilobyte 
floppy  diskette  (e.g.  the  8916ESS  scheduling  decision  aid 
requires  slightly  more  than  360  kilobytes  which  includes  the  data 
base,  menus,  spreadsheets,  and  macro  procedures) .  The  Zenith 
Z-248  with  a  20  megabyte  hard  drive  and  color  monitor  proved  to 
be  an  excellent  computer  to  host  the  6916ESS  scheduling  decision 
aid  . 

If  HQ  ESC  decides  to  provide  its  squadrons  with  ENABLE  or  a 
similiar  software  capability  and  Z-248  or  similiar  computers , 
training  is  essential.  The  ENABLE  software  capability  is 
extensive  and  if  the  squadrons  are  to  exploit  this  power,  they 
need  some  people  trained  to  use  it.  Since  the  quality  of 
personnel  in  ESC  has  trad l t l ona 1 1 y  been  high  and  since  most  are 
computer  literate,  only  one  or  two  people  would  require  formal 


training.  Those  people  receiving  the  formal  training  could  teach 
the  rest  of  the  squadron. 

System  Evaluation.  System  evaluation  is  an  important 
element  of  the  adaptive  design  process.  Not  only  does  the 
computer  code  used  to  build  the  system  need  to  be  verified,  but 
system  effectiveness  also  needs  to  be  evaluated.  The  computer 
code  written  to  build  the  6916ESS  scheduling  decision  aid  has 
been  verified  by  the  builder.  Since  the  builder  has  an  adequate 
working  knowledge  of  the  scheduling  process,  each  decision  aid 
function  was  tested  to  ensure  proper  performance.  Several 
example  mission  crews  were  scheduled  to  fly  missions  using  the 
6916ESS  scheduling  decision  aid.  Mission  Flight  Orders  were 
automatically  produced  when  requested  for  the  simulated  crews. 
Additionally,  all  mission  completion  tasks  (e.g.  update  mission 
history  and  operator  history  data  relations  and  calculation  of  30 
and  90  day  flight  hours) . 

A  System  effectiveness  evaluation  has  not  been  completed 
because  of  the  lack  of  interaction  with  the  user.  A  system 
effectiveness  evaluation  should  consider  all  aspects  of  the 
decision  aid:  the  system  itself,  the  user,  the  environment,  and 

the  task.  To  properly  evaluate  the  system,  the  scheduling 
decision  aid  needs  to  be  given  to  the  6916ESS  and  used  by  the 
schedulers.  Although  many  of  the  decision  aid’s  benefits  are 
more  qualitative  than  quantitative  (e.g.  more  alternatives 
examined,  improved  communications  between  sections,  etc.) ,  there 
are  some  quantitative  aspects  of  the  system  that  can  be  measured. 

Since  one  of  the  objectives  of  the  6916ESS  scheduling 
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decision  aid  is  to  save  the  scheduler  some  time  in  making  a  crew 
selection,  time  is  an  important  measure  of  system  effectiveness. 
In  order  to  evaluate  this  measure  of  effectiveness,  the  time 
required  to  perform  the  scheduler  functions  (e.g.  select  an 
entire  mission  crew,  find  a  replacement  operator,  complete  the 
flight  orders,  compute  30  and  90  day  flight  hours,  etc.)  manually 
and  with  the  use  of  the  decision  aid  should  be  compared.  The 
6916ESS  schedulers  have  been  asked  to  keep  records  of  the  time 
required  to  complete  the  scheduling  functions  manually.  If  the 
use  of  the  decision  aid  does  not  save  time,  either  it  must  be 
designed  to  work  faster  or  the  system  should  be  seriously 
considered  for  cancellation  if  the  crews  selected  with  the  help 
of  the  decision  aid  are  no  better  then  using  the  manual  method. 
Another  measure  of  effectiveness  is  system  response  time.  If  the 
system  is  too  slow  in  reacting  to  the  user  commands,  the  decision 
process  is  interrupted  and  thus  the  scheduler’s  decision  making 
effectiveness  could  decrease.  This  evaluation  criteria  can  be 
measured  by  observing  the  scheduler  using  the  decision  aid  and 
from  feedback  given  by  the  scheduler. 

The  time  required  for  the  scheduler  to  learn  how  to  use  the 
system  is  important.  If  it  takes  too  long  for  the  scheduler  to 
learn  how  to  use  the  system,  it  may  not  be  worth  implementing. 

The  exact  point  at  which  the  user  is  said  to  have  'learned  the 
system'  is  difficult  to  determine.  However,  the  number  of  times 
a  user  requires  assistance  from  the  user's  guide  for  routine 
operations  and  the  number  of  errors  the  user  makes  when 
proceeding  through  the  decision  process  could  be  used  to  help 
determine  the  point  at  which  a  user  has  'learned  the  system.' 


5-8 


<1  VWWMi  l*.  LWJUUIWW 


THHIW 


Selection  of  a  qualified  mission  flight  crew,  while  flying  as 
many  trainees  as  possible,  is  another  objective  of  the  6916ESS 
scheduling  decision  aid.  Since  squadron  management  would  not 
allow  a  mission  to  be  canceled  because  a  qualified  crew  was  not 
scheduled,  the  number  of  missions  canceled  because  of  a 
scheduler's  error  cannot  be  used  to  measure  crew  scheduling 
effectiveness.  As  a  result,  this  system  objective  is  difficult 
to  measure  directly  and  requires  psuedo-measures  such  as: 
comparing  the  number  of  times  a  scheduler  tries  to  assign  an 
unavailable  or  unqualified  operator  during  manual  scheduling 
versus  the  number  of  times  these  mistakes  are  made  when  using  the 
decision  aid.  Squadron  management  could  also  subjectively 
compare  mission  flight  crews  scheduled  manually  and  those 
scheduled  using  the  decision  aid  in  areas  such  as:  experience 
mix,  number  of  trainees  scheduled,  changes  required  because  of 
qualification  or  availability  mistakes,  number  of  trainer/trainee 
mismatches,  and  the  number  of  open  seats. 

The  final  and  perhaps  the  most  important  measure  of  system 
effectiveness  is  system  usage  --  or  more  simply  does  the 
scheduler  like  the  decision  aid  and  does  he  use  it.  This  item 
can  be  measured  by  asking  the  user  or  having  the  user  keep  a  log 
of  system  usage  and  recommendations  for  system  improvement. 

• 

Adaptive  Design  Methodology. 

The  adaptive  design  methodology  proved  to  be  an  effective 
way  of  building  the  6916ESS  scheduling  decision  aid.  The 
strengths  of  the  adaptive  design  methodology  as  discussed  in 
'hapter  II  proved  to  be  true  during  this  research  project.  The 
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Representation,  Operations,  Memory  Aids,  and  Control  Aids  (ROMC) 
approach  as  executed  through  the  storyboarding  process  was  quite 
effective  in  helping  to  define  requirements.  The  adaptive  design 
methodology  allowed  the  system  to  be  designed  and  partially 
implemented  without  having  all  the  requirements  "finalized* 
because  requirements  are  never  final.  This  encourages  more 
experimentation  during  system  design  and  implementation.  The 
freedom  to  experiment  leads  to  a  more  robust  system  and  more 
entries  in  the  "hook  book."  An  atmosphere  conducive  to 
generating  ideas  for  system  enhancement  and  expansion  requires  a 
system  to  capture  these  ideas.  When  multiple  users  maintain 
individual  "hook  books",  a  referee  is  needed  to  consolidate 
and/or  resolve  conflicts  among  ideas  for  implementation. 

Although  the  adaptive  design  methodology  was  effective,  it 
also  had  some  drawbacks.  One  of  the  primary  reasons  adaptive 
design  can  be  effective  is  a  strong  and  frequent  builder  -  user 
interaction.  Due  to  the  distance  and  lack  of  timely 
communications  between  the  6916ESS  and  AFIT,  there  was  very 
little  builder  -  user  interaction.  As  a  result,  the  design  and 
implementation  processes  were  not  as  effective  as  they  could  have 
been.  With  constant  builder  -  user  interaction,  the  design  and 
implementation  phases  could  have  been  accomplished  much  quicker. 

Recommendations ■  Once  a  decision  aid  is  fielded  and  becomes 
operational,  it  must  continue  to  evolve  to  meet  changing 
requirements  and  conditions  or  it  will  cease  to  be  effective. 

The  organization  needs  to  set  up  a  planning  and  design  mechanism 
to  ensure  the  system  continues  to  evolve.  This  process  must 


nr  •vw-jv'jv'jv-jY'rrjv'jYv*  v  ”  v  r*"TT  rrr?  v.v:  ?  7  vv  »ywyr  re  rerere  w^jrnrjv.vjrxr'K'v  r  v  ^  1 ■  iw  v*i 


include  a  system  to  record  user  complaints  and  suggested 
improvements,  fix  shortcomings,  implement  suggested  improvements, 
and  document  any  changes  to  the  system.  As  discussed  earlier, 
the  ‘hook  book'  system  is  an  effective  way  to  record  user 
recommendations  for  system  changes  and  can  be  implemented  with 
either  formal  or  informal  procedures. 

The  Builder’s  Perspective.  From  the  builder’s  perspective, 
the  adaptive  design  methodology  is  an  effective  way  of  designing, 
building,  and  implementing  decision  aids.  The  lack  of  timely  and 
frequent  interaction  with  the  user  caused  several  problems  and 
highlighted  the  importance  of  this  interaction  during  the 
adaptive  design  process.  Since  the  builder  did  not  have  an 
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extensive  computer  background  prior  to  building  the  6916ESS 
scheduling  decision  aid,  the  adaptive  design  methodology  proved 
to  be  a  useful  roadmap  for  decision  aid  development.  The 
experience  gained  during  this  project  shows  that  adaptive  design 
can  also  be  successfully  implemented  at  the  squadron  level  as 
more  powerful  computer  hardware  and  software  provide  squadron’s 
with  the  capability  to  design,  build,  and  implement  their  own 
computer-based  decision  aids. 


5-1  1 


APPENDIX  A 


STORYBOARDS 


This  appendix  contains  a  sample  selection  of  the  storyboards 
developed  during  the  adaptive  design  process.  They  have  been 
left  in  original  format  to  emphasize  the  fact  that  they  were  made 
quickly  and  are  best  left  in  rough  form.  The  storyboards  may  be 
changed  at  any  time  due  to  new  requirements  of  other  situation 
changes.  The  storyboards  have  been  reduced  in  size  to  comply 
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—  This  SOREEN  wOluC  ALi_uw  the  USE?  TO  OhANOE  the  CREw  com?  OS  I ' : On  “0?  A 

mission  in  response  to  different  feouifemen's.  it  would  also  allow  thf  user 

to  SET  THE  NUMBER  OF  'RAINING  POSITIONS  THERE  WILL  BE  ROR  A  PC^IC'JLmF 
MISSION. 

--  if  the  lser  answers  ves  to  the  question,  the  cursor  would  afrear  under 

I -■RE  1.  The  USEc  COUlD  Then  POSITION  •'•he  CURSOR  WhEcE  he  WAN'fC  TO  MA*  E  A 
C-AN3E . 


out 


MISSION  DATA 

HAPS  SCHEDULE 

EVALUATIONS 

INF-JT  CE'S££.'EtS  Af*--£ 

COHP  !i_E  CPE* 

ispla.  cfew 
AAnGE  CFEw 
:  SSI  ON  FuANMVD  ShEE 
FlI jMt  CF££CS 


UFSA-E  F 
MI 5£ E_  _  A 


o  o 
o  u 


-/  -_t  '  r  "  i"  —  ■'■■■f'r  v.  r:  vny*  rv  \n  ~j  -.* 


COMPILE  crew 


"3=  what  mission  would  you  lI‘E  the  CP£w  COMPILE?- 

M  •  CC  *  ; 


Mc:u!N3  CC'£W 
rci^E  CO^wE^S 


<re turns  tq  9-jit 
C0mp:lIn3  •”'-*£  ; 


X  FlIGhT  C^E*  ^ENL’  wm£n  done 


MAI  N  HENu 

>  BUILD  flight  CREW 
MISSION  SChED'JuE 
0P£Ctat3p  info 
UcDATF  Inf 

UPDATE  c^ISh' 

MISCE _ anEOlS 


MISSION  OAta 
hAP£  SCHEDULE 

e  .*alu  A"  1  one 

INRuT  0&SE^.EP=  a--' 
COH«:  :UF 
D!5clAt  CREw 

C-^anoE  CPE** 

ME><  ►  A*,N  *  N” 


ri-HE.-P  FO'SALt  FC-HA I NMEN^  r4-riSSI0N  Fc-E  ■  X  *  0  Ffc-jF'A-'£  p-  _  ^3  = 

r=-aL:T 


~~  this  will  EXECUTE  the  CPEW  SwECTIOn  hE jF I  ST i C  AlGOPIThh  I  wjw_  p=; 

THE  INP'J-  SEZEI.'EC  ErOM  T M£  16Th'S  SCHEDULERS.  EXAMPLES  COULD  INC-,DE 
BuIlDING  The  CEEw  BASED  ON: 

compatibility  pE=s"viL:*f 
time  since  las’  e_:ght 
trainer  Ql*l ons 

GuAv_  I  f  I  ca *  I  ON'S  E  ^  p  Ep  I  EM;  L ”*  £jC. 0 1 


*HE  EINAl  HE  Jp  ;  ST  I  c  WILL  PPCBPRy  BE  A  combination  OE  MAN”'  AND  WlL  BP 
“CD  I E I  ED  MAN,  TIMES  B-  the  USER  .  .  _ 


,-^w  "J- - *~~- 

Jcth  ‘ 


r 


’}r-. -y  wy  ~y*.i  -ypy*>T‘^-‘T,’^k^‘^‘.v't'v:,'%'1,v.'1'T' .".■■"vr"'_,--,'.r 


f. 


i 

I 

V 

I. 


t 


n:55I3N  Planning  Sheet 

EkTEF-  MISSION  NJH&EF : _ 

POE  NfiME 

I  POhE-_ 


3uAw  k£hAFK'S 


30  90 

t  n 


c? 

1  0 

i : 


T  A  /  _  Ofc 
DIBEP" 
&P.DO 

S  Aw  0 

OlSC-'S*  • 
JACK  SON 
TR  A . :  s 
RjRG-P  5DN 
w:*Cc: 

3*  EtN 
►  NO  ? 


c 

:  i 


°c 
ioo  rrc 
ec  i^o 


70 


i 0-  Z 7 0 
40  15C 


ha:n  n£ nu 
BUILD  Pl13^t  CPE* 
MISSION  52h£DjlE 
cp-e-atqr  :%fc 

UPDATE  OcEP.ATOc  I  * 
UPDATE  Fl ! 3“’  hOj* 
HI  SCE. _ ANfc  jw3 


i : 
1 1 


toe  190 


26" 


64 

90 

l l :  30: 

1  cT 


►  CP  p 


3  4  1  Zm 
It  4E 


MISSION  CL' A 

har:  schedule 
evAu-jat:cn£ 

INF  WT  0B3E= 
COhFIwE  cre- 
d:sc'-a>  c=  e* 
•chance  CP£* 

H5**  F_hN%InG  S^E; 


.  5  _'C 

'A  mA  06*. 

'!  GP  E  Chan : t 

r  +■  -C  -  r  t 


:c£ 


c 

29  i :: 


Ti'--  l jt : 

Til  VAuJSE* 
‘--’1  S-CNE 
Ar-~C  BPAjN 
A-r;  PEP=E= 


*rc 
:  4 


;4? 
1  4 


^  c-> 


DC'  : 


DCS  : 


DO: 


C".  L-D  V0u  u>E  TC  =f  :nT  the  MFS  ON  Th£  CfiNTEE'  y  N 

Po-UPDftTE  r " 


P:-hE_=  cD-Sm.'E  FT-'-'AINMENL  F«-r I  33  I  ON  rt-Ef^I 
p  -  -  d-_:  * 


pp-:;t’ 


ThE  MP5  IS  A  AE3UIEED  PjfT  B v  fiESu.A'IDN  AND  At__0w3 
:  T  !  ONE  TQ  COORDINATE  on  T  hE  3ChEDJl_E  BEFORE  PINAl.  OFE 
:  SO'.  AL 


"he  TAJ 
O^p IDE 


A-9 


/•;q/:vg>q4vv-' 


ester  MISSION: 


*FOwE__.  michEAl  6..  MSC-T 
T*v-OR.  WILLIAM  D.,  T SGT 
DIBEP',  ThQMAS  P..  SPA 
P-3C»  ,  BA=3N  S. ,  SSGT 
SAuO .  GENE  0. .  SSG' 

OlSQvSv  V .  MICHES'-  P.,  SSGT 
JAC>Si3N,  MEERUT  P.,  S6T 
TtAvIS.  h:c>  C..  SSGT 
F JF  G  Jc SON ,  m;CmaE_  t.,  mSGT 
wINDE=.  JOHN  h.  SM3G' 

S- SEN.  S'EwAP'  f . .  'SB* 

>  NC  :  .  WA__ACE  J..  CMSGT 
OG-ESr  * ,  MAF>  r ,  ,  SGT 
t  3FC,  TmCMAS  J .  ,  CAFT 
hA*D£N.  THCMAr  A.  ,  TSGT 
VA_uSE>  ,  JOHN  F. ,  ,  SPA 
SGhQECt  ,  JAh£S  F.  ,  MSGT 
'FAFF  .  F£,|J_  E  .  ,  SPA 

&=EChAn:> .  JEFPFE'  F . ,  SSGT 
:  LUTZ.  pO-lIN  J..  SSG' 

S' One ,  &f:an  .  SG" 

■  &FAJN,  STEVE  p.,  SPA 
:  FEFFEFt.  DAVID  E..  MSGT 


.-—IN  MENU 
Bul-D  FlIjmt  CPE 
MISSION  SCHEDU-E 


INFO 

UPDATE  QF’E-  A* 

.  UPDATE  FlI jh’ 

.  .  MISOE _ ANE0J5 

OOu  -00— OOOC 

OOC  -'X.  -000  . 

^*EB«On  0  L 

ooo-oo-oooc 

mAFL  SC^EOUwE 

000-  X  —  Ol’OC 

EvAuJhMOnS 

OOO-OO-OOOC 

INF^T  ObSE^vE 

00'.  -00-00 Du 

COMPILE  cfe*. 

ooc-oo-oooi: 

00  .  -Ov-OOX 

C  f  E  »*• 

c»;  -oox 

~SN  F-ANMNG 

•  -  ;,;v. 

f_:gh-  of.de-  s 

ooc  -ov-cc-:-; 

000- -00-0 000 
OCO-OO-O-.OC 

ooo-oo-oooo 
ooo-oc— ooo-: 

00'.  -oo-OO  ;»o 

000-00-0000 
ox  -oo- jOO1. 

ouo-oc  — 'Xioo 
000-00-0000 

p  I  -  HE  _  f 
c  ;  _r,  , ;  T 


SAVE  FJ-h^  InmENU  PP-M*.SSII 


-Z-e-'^Z  Ps-JF  DA'S  f'-hC. 


--  THIS  WOULD  Al^Gw  The  USEP  tq  PP INT  OuT  THE  FlIGhT  QPOEP: 
A  PFAi.  TIME  SAVEF  OvE=  DOING  IT  MANUALLY  IN  A  TvFEWPITEP 

I  -  Jic — ^  ^  »- 


JLLl: 


a  - :  o 


VM  V  *  wlT,  IW.  A-’. 


U  m 


v  *U*  4J»  U*  )L*  \L"  ^»V»  %L"  V*  UL  "V*  U 


S 


m-1n  -cNu 

Bv!wD  PLI'3r«*  3F  Ew 
MISSION  5C'-’t3j.£ 
OPEc«TQP  In^C 
j-3-"E  OPt-^aF  :*^Z 
JP3A-E  rul&-^  hjjc: 
MI  SO-.lANEO  —  S 


REMO*E  An  0-- --'^> 
ADC  AN  0;E=-T;t 
i_  I  S'  I  N3E  SCR  ’  E 


--  T-:s  ro.’ine  w;l_  allow  the  user  tc  extract  sorts  from  the  da’a  ease  _:>e 
A  LIS’  OR  Al.  oat  in  T/CE  8  OPERATORS  THAT  ARE  NOT  AVAIlABlE  OR  ANN  C’H£R 
00~InA’!3N  OR  a”r;BhTES  AN  OPERATOR  HAS  (All  OAT  hi  t,fe  5  LEAD  ORE-a-;:; 

’  — a"  ARE  taa;»jRaS  •  .  IE  ThE  uSEP  R'EOLIRES  hE-c  In  FORMjwatinG  A  SO"’ 

0  Or*"  and  ,  HE  CAN  RIND  IT  E-  DEPRESSING  THE  HE*_C  REN  ( R  i  > 

--’-IS  RQ-’INE  WILL  BE  VEPy  IMFO=’AnT  WHEN  FILLING  IN  A  CEEw  (PROVIDES  *-£ 
■Owe: Os'  .  I’  WILL  A^SO  OJ«E  IN  VERY  HAND-  for  SEEDIA_  REOJES’S  ROR 
I  NR  OR "A- ; On  r-Or  THE  Oc S  ORRIOER  OR  QR£  SUPERINTENDENT. 


ADD  AN  OPERATOR 

wha-  REOOPC  WOULD  VCU  Ll>E  TO  ADD’ 

:_AS’  NAME  :  _ 

’  NAME : _ 

lE  I  N  I  T  I  Aw  :  _ _ 

RAN*  :  _ 

SS  AN  :  _ _ 

QR  £RAT QR  TrR£:  _ 

OuA_ IR I  DAT  I  ON: _ 

Training  S’ATjS: _ 

E  -  A,.  DATE: _ 

R l  IS-’  /  OR Eh:  _ 


uJ.lI  vOL  _IhE  TO  ACC  ANOTHER  RECORD-  V  N 


MAIN  MENU 
BuIlD  FlISh’  CREh 
MISSION  SCHEDULE 
OP  ERATOR  I  NR  0 
UP-DATE  OcERA’OR  inf; 
UPDATE  FlIG  — ’  hOj?  a 
MISCELLANEOUS 


REMOVE  AN  OP  SR  A’ OR 
ADD  An  OPERA' 0- 
LIS’INGS  SOR’S 


RI-hElR  RD-SAVE  RO-MAINMENL  R4-MISSI0N  RO-bUlLD  Ro-UR  D'A’E  F’-hC  jRi  c=  s'-R  ’ 
F  =  -OuIT 


..OwE  thE  use= 


RECORD  WHEN  SO-EONE  DO--. 


itii 


A0-A183  362 
UNCLASSIFIED 


DESIGN  OF  AN  AIRCREW  SCHEDULING  DECISION  AID  FOR  THE 
6916TH  ELECTRONIC  SE.  .  (U)  AIR  FORCE  INST  OF  TECH 
MRIGHT-PATTERSON  AFB  OH  SCHOOL  OF  ENGI.  .  T  J  KOPF 
JUN  8?  AFIT/GST/ENS/87H-9  F/O  1/2 


2/2 


<7 

MICROCOPY  resolution  test  chart 

NATIONAL  BUREAU  OF  STANDARDS  19t3- A 


t,*  < 

*  * *  * 


'sfil 


3 1 3  !  T  1 C*  '.T '.Z^Z \Z\ 

;«HA 7  3?£?ft?2?  \EE23  a\  ^PZ^ZZ"9 
NA“E: _ 

3=3r’A7~p  wee  7H£  F0LL3*  INS  ;  r  :  £07  '  - 

PFlraRY.  arc 

SECONC:  aa 

third.  type  si 

FOwPTH:  TYPE  S  5  ■' „ 

Fir  IK:  CTC 


LIKE  TC  n«K;E  aNCTHEP  U?EPTE‘» 
Y  N 


i#:>,  -£>,_ 

O _I12  FLIGHT  1PE*. 


■  >wP~aTE  0?E?a"  =  ;\r 

L'PlaTE  FLIGHT  HC_.PS 
r  I  SCELLa',0_5 


UPOaTE  ABSENCES 
P-P3E  211  aESEMES 
:>PCSITI3N  !_■»_ ;  F ;  z-Z 1 2‘ 
Training  STaTwS • 3_EwE 
TRAINER  Q_AL  IF!  1*T  I  ON 
:  EuALuaT I 3N  STaT.S 
EXPERIENCE  LEuEL 
RETURN  TC  hain  “EN_ 
QUIT 


F1-HE1P  FS-SavE  F3-MalN  ~ENw  F-i-riSSION 
F5-3UILD  FS-UP3ATE  FT-HCw?S  F3-S2RT  FS-C-IT 


-HRNY  CPERaTCRS  HauE  nCRE  THAN  ONE  Quail  F  IcaT  I  ON  .  USE  THIS  u,HE\  30“EC-. 
_i.°3PaDES  OR  SETS  QECEPT I F I  EE  .  THIS  INFORMATION  PROuIOEl  BY  THE  STa»,  r^e- 
SECTION. 


EUALUAT I  ON  STaTUS 


WH»T  QPEReTOP  NEEOS  AN  UPOATE"’ 


C=EPoT2P  HRS  THE  FOllOW I NS  EuaueTION  ST°tjS 
PCS  IT  ION. aa 
TYPE  Euai :  Q 

EuRi  due.  is  now  as 

NUMBER  OF  F1IGHTS  1EFT  BEFORE  Euai .  5 

•uC-11  YD-  LIKE  TC  MAKE  aNOTHER  UPDATE"* 

Y  N 


nai\  nrNu 
BuIlC  F1I3HT  CPE* 
MISSION  SCHEDULE 
OPERRTO?  INFORMATION 
> uPDaTE  OPEPaTCP  INFO 
UPOaTE  F1I3HT  MO-PS 
H 1 SCEllRNEOuS 

quit 

uPOaTE  asSENCES 
POSITION  3«.ai  I  F  I  0°T  I  O' 
TRaiNING  STATUS- 3-EuE 
TRaiNEP  0-01 1  FI 1®T ION 

>Eua; _ joTION  STaTwS 

EXPERIENCE  lEvEl 

RwiwPN  iw  a  I N  ^  N — 


F1-HE1P  F=-SauE  F3-Ma;\  -EN_  Ft-“ISSI3N 
F5-BuIlD  FS-uPiaTE  FT-H0-R5  FB-SOPT  F3-3.IT 


-SEIF  EXPLANATORY  H0PEFJ11Y  I  Ca\  u,PITE  a  RO_T I NE  TC  a_ 
DECPE-1ENT  THE  NUMBER  OF  FLIGHTS  LEFT  AFTEP  Each  TPo ; N I  NO  FLIGHT 


A-  12 


,(  l.f  A  .1.  . 


UPDATE  aesences 

ulHPT  OPERATOR  NEEDS  AN  ABSENCE  UPDATr-» 
NAnE ; _ 

WC_LD  YOU  LIKE  TO  ADC  OF  DELETE  FROr  THE 
ASSENCE  LIST'’  1-ADO  2-DELETE 


: ;  if  i  chosen  thenm 

ENTER  PERIOD  OPERATOR  wILL  SE  ABSENT 
"PC-  TC 


BUILD  FLIGHT  DPEw 
nISSIDN  SCHEDULE 
OPERATOR  INFCRhat: 

> UPDATE  OPERATOR  IN 
UPDATE  FLISHT  HO-P 
riSCELLANEOUS 
DU  IT 

>  UPDATE  ABSENCES 
P_P3E  OLD  ABSENCES 
POSITION  Oja. I": 0®: 
TRAINING  STATES  2_E 
T  =  ai  NFR  0  A'  I  r  -  ~c.~  ■ 


REASON, _  l.DNIF 

2.LEAUE 
2 .  TOY 
H . APPT 
S.HISC 

WOULD  YCL  LIKE  TC  HAKE  anDTHEP  UPDATE’ 

Y  N 

' ■  IF  2  CHOSEN  THEN  ■  . 

OPERATOR  HAS  BEN  DELETED  FRO“  THE  ABSENCE  LIST 
uCuLO  you  like  TC  -1ANE  ANOTHER  uPDaTE’ 

Y  N 


Evaluation  ST»TuS 
EXPERIENCE  LE~E_ 
RETURN  TO  ha ;n  -s 
Du  I T 


Fl-HEL?  F2-SAUE  F3-"o:n  “>ENo  FH-“ISSIDN 
FS-BuILO  FS - _?D °TE  F7-H0-RS  FB-SC°T  F9-0-IT 


m  m  u 


raining  status/QuEje 


H.ar  OPERATOR  NEEDS  AN  UPDATE’ 

9“£  ; _ _  _ _ . 

FERa TOP  HAS  A  TRAINING 'S-EUEY  STATUS  OF :  1 
RECOMMENDED  HE  FLY  UITH  CKNCX.' 

POSITION' TYPE:  PCS  12 
STATUS. i 

REDDMMSNDEC  NEXT  TRAINER:  (KNOX) 


YD-  LIKE  t: 
Y 


MAX: 


main  menu 
BUILD  FLIGHT  CPEu 
EPERaTDP  :nFD?ha-;3- 
>U?DATE  OPERATDP  INF: 
UPDATE  FLIGHT  HDvPS 
mi sdellanedjs 
Sul  T 


UPDATE  ABSENCES 
POSITION  DUAL  IF! DAT 
> TRAINING  STATUS 'OuE 

trainep  olalifidat: 
Evaluation  status 

EXPERIENCE  LEvEL 
RETuPN  TC  IAIN  nENu 
Ou  I T 


TRAINING  STATUS. 


1- TOP  PRIORITY  FOP  A  FLIGHT 

2- PPIORITY  FCP  A  FLIGHT 

3- FLY  IF  SEAT  AND  INSTRUCTOR  AUa;ua5LE 
H-LAST  PRIORITY  FOR  a  FLIGHT 

S-DC  NOT  FLY 


FI-HELP 


F2-MA  “EN_  F-1--ISSION 


FS-8_i: 


r=- 


PDATE 


F“-HD_RS  FS-S: 


FS-Du I T 


ft 


I 

\ 


EXPERIENCE  LEUEL 


U.KAT  OPERATOR  NEEDS  AN  UPDATE'7 
NAi-E  .  _ _ . 

CPEPATDP  CURRENTLY  HAS  THE  FOLLOW  INS  EXPERIENCE 
LEvELS 


pff  i~apy 

5 

SECONDARY;  TYPE  LEAD 

5 

THIRD: 

AA 

3 

FDuPTH. 

TYPE  B'U 

c 

FIFTH: 

t 

3 

*D_LC  YD-  LIKE  TC  ^Ak.E  ANCTHE?  UPDATE"7 
Y  N 


EXPERIENCE  LEvEL 


C-NCT  Dual  I F I  EC 

1- LEAST  EXPERIENCED 

2- 
3- 


H- 

5-r’CST  EXPEPIENCEC 


nAIN  PENU 

build  plight  crew 

MISSION  SCHEDULE 
OPERATOR  INFORMATION 
> UPDATE  CPERATDP  !\"C 
UPDATE  FLIGHT  HD_PS 
MISCELLANEOUS 
Quit 


:  UPDATE  absences 
TRAINING  STATUS  3wE-E 
TRAINER  OjAL I r I CttT I  ON 

:  evaluation  status 

:  >  EXPER I ENCE  LE-EL 
RETURN  TC  main  men. 

.  QUIT 


F 1 -HELP  FE-Sa^E 
FS-BuILD  Fo-UPDATE 


F3-MAIN  MEN.  Fm-“I5S:DN 
F’-HOUPS  FS-50PT  FS-DuIT 


-SIMILAR  TO  THE  COMM.EN 
THROUGH  SOME  TYPE  OF 
CONCERNS  THE  EXPER I ENi 
a  COMPUTER  HE-RISTIC  T 
LEUEL  MUST  BE  OuANTIFI 


T  about  SCHEDULING  TRAINEES.  THE  USER  GCES 
HEURISTIC  METHOD  WHEN  SCHEDULING  A  CREu.  THA7 
CE  LE~EL  OF  THE  OPERATORS  CRE* .  IN  CPOE?  FOP 
0  HELP  THE  .SEP  DC  THE  SAME.  7HE  EXPERIENCE 


H 


! 


A-  15 


VA  .  '.'Wa'a"  O  O  O 


PHYSIOLOGICAL  training 


WOULD  you  LIKE  TOi  1  -  UPDATE  PHYS I OLOG I  CAL  TRAINING 

DUE  DATES 

2  -  DISPLAY  LIST  OP  OPERATORS  DUE 
PHYSIOLOGICAL  TRAINING 

i  < IP  1  CHOSEN)  > 

WHICH  OPERATOR  NEEDS  UPDATE- 

NAH£ : _ 

NEW  DUE  DATE : _ 

WOULD  YOU  LIKE  TO  UPDATE  ANOTHER  OPERATOR'S 
DUE  DATE-  Y  N 


MAIN  MENU 

build  flight  crew 
MISSION  SCHEDULE 
OPERATOR  INFO 
UPDATE  OPERATOR  INFO 
update  flight  hours 
,  MISCELLANEOUS 


jj  PHYSIOLOGICAL  trng 
SV-S3  TRNG 
life  support  trng 
flight  physicals 


i  ( IF  2  CHOSEN)  ) 


LIST  OPERATORS  DUE  PHYSIOLOGICAL  TRAINING  IN  THE  NEXT: 
1  -  30  DAYS 

2- 43  DAYS 

3- 60  DAYS 

4- 90  DAYS 

3  -  120  DAYS  CHOOSE  ONE: _ 

jAM£  DUE  DATE 


F 1 “HELP  F2-SAVE  F3-MA I NMENU  F4-MISSI0N  F3-BUILD  F6-UF  DATE  F7 -HOURS  F8-50PT 
F9-QUIT  - 

|  -  -  _ 

i 

I 

I 

j  —  THIS  ALLOWS »THE  USER  TO  UFDATE  AN  OPERATORS  PHYSIOLOGICAL  TRAINING  AND 

;  also  DISPLAYS  OPERATOR'S  WHO  ARE  DUE  PHYSIOLOGICAL  training.  IF  AN  OFEPATOC 

I  -ISSES  His  TRAINING  DUE  DATE  HE  IS  GROUNDED,  SO  THIS  IS  A  GOOD  THING  TQ  > EEF 

i  CLOSE  TRACK  OF. 


I 

I 

I 


I 

I 


I 


APPENDIX  B 


i 

USER’S  GUIDE 


For 

0916th  Electronic  Security  Squadron 
Scheduling 
Decision  Aid 


This  manual  is'  designed  for  the  6916ESS  schedulers  who  will  use 
this  system.  Since  the  system  is  somewhat  complicated  and 
involves  transferring  data  between  different  software 
applications,  the  user  should  be  familiar  with  the  ENABLE 
software  package  before  using  this  decision  aid.  The  User's 
Guide  does  provide  some  examples  of  common  decision  aid 
operations  and  includes  example  screen  displays.  Additional 
technical  information  concerning  this  decision  aid  can  be  found 
in  Appendix  C. 


USER’S  3UIDE 


This  manual  is  divided  into  eight  sections  corresponding  to  the 
options  in  the  main  menu,  a  section  concerning  system  start 
up  and  general  information,  and  a  list  of  executable  menus: 


Section  1 
Section  2 
Section  3 
Section  4 
Section  5 
Section  6 
Section  7 
Section  8 


System  Start-up  &  General  Information 

Build  Flight  Crew 

Mission  Schedule 

Operator  information 

Mission  Completion  Actions 

Mi  seel laneous 

Flight  Orders 

List  of  Menus 


SECTION  1:  System  Start-up  &  General  Information 


General  Information 

Input  Commands.  Commands  the  user  should  input  are 
identified  by  all  capital  letters  and  bold  print  (e.g.  RETURN  for 
the  return  key  or  ESC  for  the  escape  key) . 

Simultaneous  Commands.  Many  times  the  user  will  have  to 
strike  two  keys  simultaneously.  For  example,  to  display  a  menu, 
the  user  will  have  to  strike  the  CTRL  key  and  the  F10  key 
simultaneously.  When  required,  simultaneous  commands  are 
identified  by  the  notation  KEY/KEY  (e.g.  CTRL/F10  would  mean 
strike  the  CTRL  and  the  F10  keys  simultaneously) . 

Menu  Option  Execution.  To  execute  a  menu  option,  hit  RETURN 
when  the  option  is  highlighted  with  bold  colors.  You  may  move 
from  one  menu  option  to  another  by  using  the  arrow  keys. 

Notepad.  A  notepad  capability  has  been  included  in  this 
system  for  use  by  the  scheduler  to  document  system  problems  or 
proposed  system  enhancements.  The  notepad  can  and  should  also  be 
used  to  take  notes  during  the  scheduling  process  (e.g.  while  in 
the  middle  of  developing  a  schedule  with  the  system,  the  Ops 
Superintendent  comes  in  the  office  and  says  he  wants  to  fly  next 
Tuesday  --  all  you  have  to  do  is  hit  ALT/F9  then  N.  You  will 
automatically  go  to  the  notepad.  Type  in  the  note  to  yourself. 
When  you  are  done,  you  can  go  back  to  where  you  were  by  hitting 
ALT/DOWN  ARROW) . 

Saving  Your  Work.  Anytime  you  would  like  to  save  you  work 
(e.g.  mission  crew  spreadsheet)  hit  ALT/F10  and  follow  the  system 
instructions.  If  you  would  like  to  close  the  window  after  saving 
you  work,  hit  ALT/END. 


Data  Baaa .  It  is  very  important  that  the  data  base  be 
located  in  window  #1.  If  for  some  reason  the  data  base  is 
removed  from  window  *1  (e.g.  you  accidentally  close  the  daia  base 
window) ,  you  need  to  save  any  work  that  needs  saving,  then  close 
all  windows.  After  all  windows  have  been  closed,  restart  the 
decision  aid  by  hitting  CTRL/F10  then  A. 

The  same  is  true  for  the  notepad.  The  notepad  must  be 
located  in  window  *2  at  all  times. 

Conditions  for  Menu  Option  Execution.  Before  executing  any 
option  from  the  main  menu,  ensure  all  windows  except  window  #1 
(data  base)  and  window  *2  (notepad)  are  closed. 


System  Start-up 

After  you  have  entered  the  ENABLE  software  package  and  the 
ENABLE  main  menu  is  displayed,  you  can  enter  the  decision  aid  by 

typing : 

CTBL/F10  then  A 

The  system  logo  will  appear  on  the  screen  as  shown  in 


CFES5  RETURN  TC  CONTINUE 


Figure  B.l  System  Logo 


As  instructed,  hit  RETURN  to  continue.  The  system  wi 1 .  • 

a  couple  of  minutes  (if  working  on  a  hard  drive  computer)  t 
the  data  base  and  the  notepad  and  will  then  display  the  MAI).' 
MENU  as  shown  is  Figure  B.2.  If  you  would  like  to  display  the 
Main  Menu  while  working  with  the  decision  aid  (e.g.  to  move  to 
another  function) ,  hit 


CTRL/F 10  then  A 


.JM 


V  0£  Mu 

ve=  v-s 


;  r  r.-.rOc»-~  ;;g;|  , 


ESC ■ 


Figure  B.2  Main  Menu 


SECTION  2:  BUILD  FLIGHT  CREW 


When  the  Main  Menu  is  displayed,  selection  of  the  BUILD 
FLIGHT  CREW  OPTION  will  result  in  the  BUILD  FLIGHT  CREW  MENU  to 
be  displayed.  This  menu  is  shown  in  Figure  B.3. 


nul'.  *i£rv_ 


r>  J  i  -u  -  _  .  jf 


Figure  3.3  Build  Flight  Crew  Menu 

Enter  the  mission  number  of  the  mission  you  would  like  to 
work  on . 

Next,  answer  the  question  have  you  worked  on  this  mission 
before.  If  you  answer  yes,  the  system  will  go  get  the  mission 


crew  spreadsheet  that  is  storea  in  the  system  and  will  then 
display  a  menu  asking  you  if  you  would  like  to  display  the 
mission  crew  or  if  you  would  like  to  select  an  operator.  T: 
:  is  shewn  in  Figure  3.4. 


Figure  B.4  Display  Mission  or  Select  Operator 


If  you  select  DISPLAY  MISSION  CREW  the  system  will  go  to  the 
mission  crew  spreadsheet.  If  after  looking  at  the  crew  you  would 
like  to  add  an  operator  to  the  crew  or  replace  a  crewmember,  hit 

CTRL/F10  then  A 

This  will  display  the  operator  selection  menu. 

If  you  choose  SELECT  AN  OPERATOR,  the  system  will  display 
the  operator  selection  menu  shown  in  Figure  B.5. 


If  you  have  not  worked  on  a  mission  crew  bef 
answer  NO  to  question  in  the  Build  Flight  Crew  Me 
then  be  asked  what  type  of  mission  is  scheduled. 
TYPE  1  or  TYPE  2. 

After  choosing  the  type  of  mission,  the  syst 
spreadsheet  and  set  up  the  proper  crew  compositio 
of  mission.  Next,  a  menu  will  be  displayed  askin 
like  to  hard  schedule  and  operator  (If  you  would 
schedule  an  operator  anytime  you  are  working  on  a 
hit  CTRL/F10  then  E  and  answer  YES) .  Thi 

in  Figure  B.6. 

If  you  would  like  to  hard  schedule  an  operat 
and  then  type  in  the  operator’s  last  name.  The  s 
you  to  the  data  base  where  you  must  mark  the  oper 
key  in  preparation  of  moving  information  from  the 
the  mission  spreadsheet  (see  Figure  B.7).  To  mar 
the  data  base,  put  the  cursor  on  the  name  of  the 
hit  F7 .  Once  the  operator  has  been  marked,  go  ba 
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mission  spreadsheet  by  hitting 

F9  then  W  then  3  then  G 

((  NOTE:  this  assumes  you  only  have  one  mission  crew  spreadsheet, 
open.  If  you  have  more  than  one  open,  hit  F9  then  W  then  ?  and 
choose  the  mission  you  want  to  schedule  the  operator  for)) 

After  you  are  back  in  the  spreadsheet,  put  the  cursor  in  the 
space  to  the  right  of  the  position  you  would  like  to  schedule  the 
operator  for,  then  hit 

ALT/F9  then  S 

Appropriate  information  about  the  operator  will 
automatically  be  transferred  from  the  data  base  to  the  miss:.:: 

ere >  spreadsheet  as  shown  in  Figure  B.8. 
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Figure  B.5  Operator  Selection  Menu 
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Figure  B.7  Data  Base  Example  for  Hard  Scheduling 
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F  .re  B.8  Mission  Crew  Spreadsheet  after  Hard  Schedule 


If  you  do  not  wish  to  hard  schedule  an  op,  choose  NO  and  the 
system  will  take  you  to  the  operator  selection  menu  shown  in 
F igure  B . 5 . 

If  you  do  not  wish  to  select  an  operator,  you  can  go 
directly  to  the  mission  crew  spreadsheet  by  hitting 


SECTION  3:  MISSION  SCHEDULE 
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Figure  3.9  Mission  Schedule  Menu 


Choosing  the  DISPLAY  MISSION  SCHEDULE  option  produces  a  menu  that 
asks  for  a  start  date  for  the  missions.  For  example,  if  you 
would  like  to  see  all  the  missions  scheduled  after  2  Jan  87,  you 
would  input  87,01,02  as  shown  in  Figure  B.10.  When  entering  the 
date,  you  must  put  it  in  YY.MM.DD  format. 
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Figure  E.il  Operator  Update  Menu 
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Figure  B.12  Operator  Add  Menu 


If  you  choose  the  CHANGE  A  RECORD  option,  the  Operator 
Change  Menu  will  be  displayed  on  the  screen.  This  menu  is  shown 
in  Figure  B.13.  Again,  if  you  follow  the  instructions  given  in 
the  menu,  you  should  have  no  problems.  The  instructions  from  the 
menu  are  repeated  here  for  you. 


Your  choice  will  take  you  to  the  appropriate  data  base.  To 
change  a  record  (edit)  ,  simple  mark  the  appropriate  record  using 
the  F7  function  key,  press  ESC  twice,  then  press  "E".  The  record 
can  now  be  changed. 

•**  NOTE:  If  you  change  the  SSAN,  you  must  change  it  in  all 
relations.  »»» 


If  you  choose  the  DELETE  A  RECORD  option,  the  Operator 
Delete  Menu  will  be  displayed  as  shown  in  Figure  B.14.  Again, 
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Figure  3.13  Operator  Change  Menu 
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Figure  B.14  Operator  Delete  Menu 


Your  choice  will  take  you  to  the  appropriate  data  base.  To 
delete  a  record:  L  __  .  „  .  . 


1) 
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If  you  choose  the  UPDATE  OPERATOR  FLIGHT  HISTORY  DATA  BASE 
option,  the  system  will  ask  you  for  the  mission  number.  After 
you  have  provided  the  mission  number  the  system  will  transfer 
data  from  the  mission  crew  spreadsheet  to  the  MSNDONE  spreadsheet 
in  preparation  for  updating  the  OPHISTY  data  base.  The  system 
will  prompt  you  for  the  mission  date  --  input  the  date  in 
YY.MM.DD  format.  Next  the  system  will  ask  for  the  mission 
duration.  After  you  have  provided  that  information,  the  system 
automatically  updates  the  data  base  and  closes  the  spreadsheet 
w  i  n  d  o  ws  . 

If  you  choose  the  30  DAY  UPDATE  option,  the  system  will 
compute  each  operators  30  day  flight  hours  (if  they  have  flown  m 
the  past  30  days) .  If  a  mission  has  been  completed  execute  the 
UPDATE  OPERATOR  FLIGHT  HISTORY  DATA  BASE  option  before  doing  the 
30  or  90  day  flight  hours.  The  system  will  ask  you  for  the  30 
day  window  with  the  prompt 

Where  :  DATE  GE 

Enter  the  30  day  window  (e.g.  30  days  ago)  in  YY.MM.DD  format 
(e.g.  if  today  was  14  Apr  87,  then  the  30  day  window  would  be 
input  as 

•87,03, 14' 

An  example  is  shown  in  Figure  B.17.  It  is  very  important  that 
you  put  quotation  marks  ('  ")  around  the  date  or  the  system 

will  give  you  an  error.  Once  you  have  give  the  system  the  30  day 
window,  the  system  will  automat i ca 1 1 y  compute  each  operator’s  30 
day  flight  hours  and  update  the  data  base  with  the  new  numbers. 
This  process  may  take  several  minutes  to  complete  on  a  hard  disk 
system  (longer  on  a  floppy  only  system)  so  do  not  get  impatient. 
If  for  some  reason  the  system  is  not  working  after  a  cons.i-r 
amount  of  time,  press  CTRL /BREAK.  If  the  system  still  doe:  ..  * 

W'  rk  .  :  )wer  cycle  and  start  over. 
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The  90  DAY  UPDATE  option  works  much  the  same  way  as  tne  ol 
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DAY  UPDATE  option  works.  The  system  will  prompt  you  for  the  SO 
day  window  m  the  same  way  it  asked  for  the  30  day  window.  One 
you  have  given  the  system  the  90  day  window,  the  system  will 
automatically  calculate  the  90  day  hours  and  update  the  data 
base.  For  more  information,  read  the  section  on  the  30  DAY 
UPDATE  option  above. 

The  ADD  INDIVIDUAL  HOURS  option  will  display  the  Operator 
Flight  Hour  Input  Form.  This  option  should  be  used  when  an 
operator  accumulates  flight  hours  on  aircraft  or  missions  other 
than  those  flown  from  the  6916th.  The  input  form  is  shown  m 
”.  .re  3.18.  The  form  is  pretty  self  explanatory  --  ; us t  f l  ’  ' 

t  l  ■  t  a  -  *  3  *.-%».  V  ^  t  a  .v.  io  a  2  -  q  *■  -  a  a J  *•  - 

:  m  nor  does  the  MISSION  NUMBER  item. 
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Figure  B.18  Operator  Flight  Hour  Input  Form 

SECTION  6:  MISCELLANEOUS 


The  Miscellaneous  Menu  is  shown  in  Figure  B.19.  Thic 
function  was  designed  to  allow  the  scheduler  to  keep  track  of  u 
requires  recurring  training.  All  four  menu  options  take  you  to 
the  OPERATOR  data  base  and  allow  you  to  input  your  own  "WHERE" 
specifications.  For  example,  if  you  were  interested  i n  who 
needed  physiological  refresher  training  in  the  next  6  months  so 
you  could  make  TDY  arrangements  well  in  advance,  at  the  WHERE 
prompt  you  would  type 

PHYSIO  LT  ■01,11,03* 

((This  assumes  that  physiological  refresher  is  every  6  years  an 
that  "todays"  date  is  3  Apr  87) ) 
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Figure  3.1-5  Miscellaneous  Menu 

SECTION  7:  FLIGHT  ORDERS 


he  Flight  Orders  Menu  is  shown  in  Figure  3.11 


Figure  5.10  Flight  Orders  Menu 


As  you  can  see,  the  system  asks  you  which  mission  you  would 
like  to  work  on  orders  for.  After  you  enter  the  mission  number, 
answer  the  question  on  whether  you  have  worked  on  these  orders 
before  . 


Have  Not  Worked  on  This  Mission's  Flight  Orders  Yet.  I: 

ive  not  worked  on  these  orders  yet,  answer  NO  to  the  quest! 
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The  system  wi 1 i  automatically  open  a  word  processing  document  fo 
you.  The  system  will  automatically  prompt  you  for  all  the 
information  it  can  not  get  from  the  mission  crew  spreadsheet. 

The  system  will  first  ask  you  for  the  expected  land 
date.  Next,  you  will  be  asked  for  the  date  and  takeoff  time.  A 
display  of  this  prompt  is  shown  in  Figure  B.21.  In  the 
background,  you  can  see  the  expected  land  date  was  inserted  ir. 
the  upper  right  hand  corner.  The  date  in  the  upper  left  hand 
corr0"  was  transferred  from  the  mission  crew  spreadsheet.  T>i* 

:  *. .  r.  formation  displayed  m  Figure  B.21  was  inserted  bv 

-vs  flight  orders  program. 
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Figure  B.21  Date  and  Take  Off  Time  Prompt 

Next,  the  system  will  asked  you  for  today's  date,  and 
then  it  will  ask  for  the  order  number. 

The  system  has  now  completed  the  flight  orders  and  ask 
you  if  you  would  like  to  examine  the  orders  or  make  changes. 

This  is  shown  in  Figure  B.22. 

If  you  do  not  wish  to  examine  the  orders  answer  NO  and 
the  system  will  display  the  Flight  Orders  Print  Menu  shown  in 
Figure  B.22.  If  you  would  like  to  print  the  orders,  the  system 
will  ask  you  to  insert  the  orders  into  the  printer  and  and  hit 
return.  If  you  would  not  like  to  print  the  orders,  the  system 
will  ask  you  if  you  want  to  make  any  changes. 

If  you  want  to  examine  the  orders,  answer  YES.  The 
system  will  send  you  to  the  flight  orders  word  processing  file 
where  you  can  examine  the  flight  orders  before  you  type  them. 
When  finished  looking  at  the  orders  type 


CTRL/F10  then  K 


uc  r 
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INSERT  ORDERS  IN  -he  PRIN-ER  PND  hit  pe-jrn  when  PEPCv 


Figure  3.22  Flight  Orders  Print  Menu 


SECTION  8:  LIST  OF  MENUS 

Table  B.l  contains  a  list  of  menus  you  may  call  while 
working  with  the  decision  aid.  To  display  any  of  the  menus  h 

CTRL/F10 

followed  by  the  letter  designator  listed  below. 


Table  B.l  List  of  Menus 


Letter  Designation 
A 
B 
C 
N 
E 
2 
S 
U 
F 


Title 

System  Logo 

Build  Flight  Crew  Menu 
Mission  Completion  Menu 
Main  Menu 

Hard  Schedule  an  Operator  Menu 
Operator  Selection  Menu 
Mission  Schedule  Menu 
Operator  Update  Menu 
Flight  Orders  Menu 
Flight  Orders  Change/Print  Menu 


APPENDIX  C 


MAINTAINED  S  MANUAL 
For 

0916th  Electronic  Security  Squadron's 
Schedul ing 
Decision  Aid 


This  manual  is  designed  for  the  naintainer  of  the  6S16ESS 
Scheduling  Decision  Aid  and  is  to  be  used  in  conjuction  with  the 
ENABLE  documentation.  The  manual  is  incorporated  in  Appendix 
format  to  allow  for  extraction  as  a  stand-alone  document. 
Additional  information  about  this  decision  aid  can  be  found  m 
Appendix  B  (User’s  Guide) . 


MAINTAINED ' S  MANUAL 


This  manual  is  written  for  the  individual  responsible  for 
maintaining  the  6916ESS  scheduling  decision  aid.  The  maintair.er 
should  have  a  good  working  knowledge  of  the  capabilities  of 
ENABLE.  This  manual  is  divided  into  four  sections: 
spreadshee ts ,  data  base,  menus,  and  macro  procedures. 


Section  1.  SPREADSHEET  MAINTENANCE.  The  spreadsheets  used  or 
created  in  the  6916ESS  scheduling  decision  aid  and  their  purpose 
are  listed  in  Table  C.l. 


Table  C.l  Spreadsheets 


NAME 


PURPOSE 


THIRTY 


NINETY 


LLNNN 


TYPE  1 

TYPE2 

H0URS3 

H0URS9 

ORDERS 

WORKSKED 

MSNDONE 


Used  during  calculation  of  30  day  flight 

hours.  This  spreadsheet  holds  the  data  to  update 

the  data  base . 

Used  during  calculation  of  90  day  flight  hours. 
This  spreadsheet  holds  the  date  to  update  the 
data  base. 

These  are  the  mission  crew  spreadsheets  where  LL 
stands  for  2  letters  and  NNN  stands  for  3  numbers 
(e.g  DL150).  Contains  the  crewmembers  names, 
positions,  and  other  data  for  each  mission  crew. 

Profile  for  position  configuration  for  Type  1 
miss  ions . 

Profile  for  position  configuration  for  Type  2 
missions . 

Used  to  calculate  the  30  day  flight  hours 

Used  to  calculate  the  90  day  flight  hours 

Used  to  transfer  crewmember’s  names  and  SSANs  free 
the  mission  crew  spreadsheet  to  a  word  processing 
file  for  flight  orders  preparation. 

Contains  the  rotating  work  schedule  for  each  crew. 

Used  to  transfer  operator  information  from  a 
mission  crew  spreadsheet  to  the  OPHISTY  data  base 
relation. 
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Section  2.  DATA  BASE  MAINTENANCE.  The  6916ESS  scheduling 
decision  aid  uses  6  data  relations.  A  detailed  discussion  of 
each  relation  is  located  in  Chapter  IV.  The  Tables  defining  eac 
relation  in  Chapter  IV  are  reproduced  in  this  manual  for  easier 
use  by  the  mamtainer.  Maintenance  of  the  data  within  each  data 
relation  is  handled  from  within  the  decision  aid  itself.  For 
more  information  see  Appendix  B. 


Table  4.3  ABSENT. DBF  Relation 


Field  Name 

Description 

Purpose 

SS  AN 

Operator’s  Social 

Number 

Allows  scheduler  to  link 
to  other  data  relations 

START 

Date  Operator  becomes 
Unavai lable 

Used  during  searches  for 
available  operators 

STOP 

Date  Operator  becomes 
Avai lable 

Used  during  searches  for 
available  operators 

REASON 

Reason  Operator  is 

Unavai lable 

Used  to  answer  queries 
why  an  operator  is 
unavai lable 

The  following  field  names  access  data  from  the  OPERATOR 
relation:  (see  Table  4.1) 


LASTNAME,  FIRSTNAME 
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Table  4.1  OPERATOR. DBF  Data  Relation 

FIELD  NAME _ DESCRIPTION _ PURPOSE 


* 

8 

! 

s 

V 

I 


SS  AN 

Operator’s  Social 

Security  Number 

Used  as  a  unique  iden¬ 
tification  number  which 
allows  integration  of 
several  relations 

LASTNAME 

Operator ’ s  Last 

Name 

Used  by  the  scheduler  as 
the  primary  means  of 
identifying  an  operator 

FIRSTNAME 

Operator's  First 

Name 

Used  in  conjunction  with 
an  operator’s  last  name 

MI 

Operator's  Middle 

Initial 

Used  in  conjunction  with 
first  and  last  names 

RANK 

Operator ' s  Rank 

Used  for  Flight  Orders 
and  crew  balance 

TYPE 

Operator ’ s  General 

Type 

Used  for  general  data 
base  searches  for  squa¬ 
dron  management 

CREW 

Operator's  Work  Crew 
(Able,  Baker.  Charlie, 
Days  ) 

Used  for  data  base  sear¬ 
ches  to  identify  opera¬ 
tors  for  a  mission 

THIRTY 

Number  of  Flight  Hours 
an  Operator  has  over 
the  past  30  days 

Used  to  insure  an  opera- 
does  not  exceed  AF 
limits  for  ^0  day  hours 

NINETY 

Number  of  Flight  Hours 
an  Operator  has  over 
the  past  90  days 

Same  as  THIRTY  except 
for  90  consecutive  days 
instead  of  30 

SV83 

Date  Operator  last 
attended  SV-83  training 

Used  to  schedule  opera¬ 
tors  for  SV-83  training 

E 


LIFESPT 


PHYSIO 


FLTPHYS 


Date  Operator  last 
attended  Life  Support 
Training 


Date  Operator  last 
attended  Physiological 
Training 


Date  Operator  last  had 
a  Flight  Physical 


C-4 


Used  to  schedule  opera 
tors  for  semi-annual 
life  support  training 


Used  to  schedule  opera¬ 
tors  for  recurring 
physiological  training 


Used  to  monitor  comp 
with  annual  flight 
physical  requirement 


Table  4.2  POSITION. DBF  Relation 


i 

i 

Field  Name 
SS  AN 

POSITION 

PRIMARY 

QUAL 

TRAINER 

EVAL 

EXPLEVEL 

TRNGQUE 

STRENGTH 


Description _ 

Operator’s  Social 
Security  Number 

Position  Designation 

Yes/No  field 

Position  Qualification 
Le  ve  1 

Yes / No  field 

Evaluation  Date 

Experience  Designation 

Training  Priority 

Strength  as  a  Trainer 


Purpose _ 

Unique  identifier  which 
alio ws  access  to  other 
relations 

Desgnation  for  each  posi¬ 
tion  an  op  is  qualified 
for  or  is  in  training  for 

Flag  for  an  op's  primary 
position 

Designator  for  the  qual¬ 
ification  level  an  op  has 
reached  for  a  position 

Flag  to  designate  if  an 
op  is  a  qualified  trainer 

Date  an  op  is  due  an  eval¬ 
uation  for  a  position 

Subjective  measurement  of 
an  op’s  experience  m  a 
position  --  Assigned  by 
squadron  management  -- 
Defined  for  future  model 
app 1 i cat  ions 

Sub j  ective  priority  given 
to  trainees  --  Assigned  by 
squadron  management . 

Used  to  help  match 
trainees  with  trainers 


WEAKNESS  Weakness  as  a  Trainee  Used  to  help  match 

trainees  with  trainers 


The  following  fields  access  information  from  the  OPERATOR 
relation:  (see  Table  4.1) 


LASTNAME,  FIRSTNAME,  MI,  RANK,  CREW,  THIRTY,  AND,  NINETY 

The  following  fields  access  information  from  the  ABSENT 
relation:  (see  Table  4.3) 


START,  STOP,  AND  REASON 
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Table  4.4  OPHISTY. 

.DBF  Relation 

Field  Name 

Description 

PurDose 

3  SAN 

Operator’s  Social 
Security  Number 

Used  to  access  information 
from  other  data  relations 

MISSION 

Mission  Number 
Designation 

Used  to  access  information 
from  another  relation 

DURATION 

Mission  Duration 
in  hours 

Used  to  calculate  30/90 
day  flight  hours 

POSITION 

Position  Designator 

Used  to  designate  which 
position  op  flew 

DATE 

Mission  Date 

Used  to  when  calculating 

30/90  day  flight  hours 


The  following  field  names  access  information  from  the 
OPERATOR  relation:  (see  Table  4.1) 

LASTNAME,  FIRSTNAME 


Table  4.5  MSNHI STY . DBF  Relation 


Field  Name 

Des  emotion 

Purpose 

MISSION 

Mission  Number 
Designator 

Unique  identifier  for  each 
mission 

DATE 

Mission  Date 

Date  mission  was  flown 

TAKEOFF 

Take  Off  Time 

Take  off  time  helps  deter¬ 
mine  mission  duration 

LAND 

Land  Time 

Land  time  helps  determine 
mission  duration 

DURATION 

Mission  Duration 

Used  when  determining 
total  hours  flown  by  the 
s  quadron 

ORB ITT I ME 

Mission  Orbit 

Time 

Total  time  on  orbit  helps 
determine  mission 

e  f  f  ecti veness 

WATCHTIME 

Mission  Watch 

Time 

Total  watch  time  helps 
determine  mission 
ef  f ectiveness 

STATUS 

Mission  Status 

Determined  by  planned  vs 
actual  orbit  time  --  a 
measure  of  ef f ect 1 veness 

REMARKS 

Mission  Remarks 

Used  to  add  general 
remarks  about  a  mission 

PRIORITY 

Mission  Priority 

Used  to  highlight  missions 
that  required  special 
attention  when  scheduling 
the  mission  crew 

C-7 
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Table  4.6  MISSION. DBF  Relation 


Field  Name _ Description 


Purpose 


TYPE 

NUMBER 

TAKEOFF 

LAND 

DATE 

SHOWTIME 

PRIORITY 

DURATION 


Mission  Type 

Mission  Number 

Take  Off  Time 

Land  Time 

Mission  Date 

Pre-mission  Show  Time 

Mission  Priority 

Mission  Duration 


Determines  position  con¬ 
figuration 

Unique  identification 
for  each  mission 

Scheduled  takeoff  time 
helps  determine  crewrest 
violations 

Scheduled  land  time  helps 
determine  crewrest 
violations 

Scheduled  mission  date 
determines  which  crew  is 
responsible  for  mission 
manning 

Scheduled  crew  showtime 
determined  by  scheduled 
takeoff  time 

Designator  for  missions 
that  require  special 
attention  when  schedul¬ 
ing  ere  wme  mb  e  r  s 

Scheduled  mission  duration 
determined  by  scheduled 
takeoff  and  land  times 
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Section  3.  MENU  MAINTENANCE.  The  menu  system  developed  for  th 
6915ESS  scheduling  decision  aid  controls  the  actions  of  the 
decision  aid  and  also  allows  the  user  to  work  on  his  own.  For 
each  menu  option  the  system  response  will  either  be  to  go  to 
another  menu  or  to  execute  a  macro  procedure.  The  format  for  t 
remainder  of  this  section  will  be  to  give  the  menu  name,  then  a 
replica  of  the  menu,  and  finally  the  system  action  for  each  of 
the  menu  choices. 


MENU  A:  (Logo) 


1.  Option  RETURN 

Action:  Macro  Code 

( VOFF } 

{ &HOME } 

U 

D 

I 

D  POSITION 

(&KOME) 

U  W 

R  NOTEPAD 

{ &F9  } S 
(VON) 

{  *F10)N 


Turn  video  off 

Open  a  window 

Use  the  system 

Go  to  the  data  base 

Interact  with  the  data  base 

Display  POSITION. DBF  relation 

4  Returns 

Open  a  window 

Use  the  Word  Processing  program 
Revise  WP  file  NOTEPAD . WPF 
Return 

Call  WP  macro  procedure  S 
Turn  video  back  on 
Call  Menu  N  (Mam  Menu) 


U  N:  (Main  M«nu) 


MAIN  MENU 

SELECT  ONE: 

BUILD  FLIGHT  CREW 

MISSION  SCHEDULE 

OPERATOR  INFORMATION 

UPDATE  OPERATOR  INFORMATION 

1=  MISSION  COMPLETION  ACTIONS 

2=  MISCELLANEOUS 

FLIGHT  ORDERS 

QUIT 


* 

if 

I ( 


3  . 


Option  BUILD  FLIGHT  CREW 
Action:  Go  to  Menu  3 

Option  MISSION  SCHEDULE 
Action:  Go  to  Menu  S 

Option  OPERATOR  INFORMATION 
Action:  Macro  Code 


C  F9 } WIG 
(ESC)  (ESC) 
D  POSITION 
{ 15X} (DEL) 


Go  to  Window  *1  (data  base  window, 
Go  to  the  data  base  actions  menu 
Display  POSITION  relation 
15  deletes  to  delete  an  unwanted 
characters 


4  . 


5  . 


6  . 


Option  UPDATE  OPERATOR  INFORMATION 
Action:  Go  to  Menu  U 

Option  MISSION  COMPLETION  ACTIONS 
Action:  Go  to  Menu  C 

Option  MISCELLANEOUS 
Action:  Go  to  Menu  MISC 

Option  FLIGHT  ORDERS 
Action:  Go  to  Menu  F 


8 .  Opt i on  QUIT 

Action:  Go  to  Menu  QUI' 
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MENU  B:  (Build  Flight  Cr«w) 


BUILD  FLIGHT  CHEW 

ENTER  MISSION  NUMBER:  _ 

HAVE  YOU  WORKED  ON  THIS  MISSION  BEFORE 9 
YES  NO 

WHAT  TYPE  MISSION  IS  THIS9 
TYPE  1  TYPE  2 


Option  ENTER  MISSION  NUMBER 

Action:  Puts  the  mission  number  in  memory  for  iaier  use 

Goes  to  YES  field 

Option  YES 
Action:  Macro  Code 


{ &HOME } 

US 

R  [-/.MISSION] 


(F2)  AT 


{ *F10)D 


Open  window 

Use  spreadsheet  application 
Revise  mission  crew  spreadsheet  for 
appropriate  mission  (entered  m 
option  1 ) 

Return 

Go  to  space  A 1  in  the  spreadsheet 
and  Return 
Go  to  Menu  D 


Option  NO 

Action:  Go  to  TYPE  1  field 


Option  TYPE  1 

Action:  Macro  Code  (creates  a  mission  type  1  spreadshee 


{ &HOME } 

US 

C  [’/.MISSION] 
(&F9  >  3 
F10)E 


Open  window 

Use  spreadsheet  application 
Create  a  mission  crew  spreadsheet 
Call  SS  Macro  procedure  3 
Go  to  Menu  E 


Option  TYPE  2 

Action:  Macro  Code  (creates  a  mission  type  2  spreadsheet1 


{ &HOME ) 

US 

c  [-/.mission: 

{ &F9 } 2 
{ *F10  ■  E 


Open  window 

Use  spreadsheet  application 
Create  a  mission  crew  spreadsheet 
Call  S  S  Ma  crc  procedure  3 
Go  to  Menu  E 


MENU  E; 


WOULD  YOU  LIKE  TO  HARD  SCHEDULE  AN  OP" 
YES  NO 

ENTER  OPERATORS  L AST NAME :  _ 


Option  YES 

Action:  Go  to  option  ENTER  OPERATORS  LASTNAME 


2 .  Option  NO 

Action:  Go  to  Menu  D 

3.  Option  ENTER  OPERATORS  LASTNAME 

Action:  Macro  Code 


{F9} WIG 
(ESC) (ESC) 
D  POSITION 
{ 15X) (DEL) 

LASTNAME  = 


;  ;  Go  to  window  *1  (data  base) 

; ;  Go  to  data  base  actions  menu 
;;  Display  POSITION  relation 
;  ;  Delete  unwanted  characters 
; ;  2  Returns 

' [ %LASTNAME ] ' ~  ;;  Specification  for  data 

base  search 


LASTNAME . FIRSTNAME , MI , RANK , CREW, SSAN 

; ;  Return 


Def  imtion 
data  field 
to  display 


MENU  D: 


WOULD  YOU  LIKE  TO: 

DISPLAY  MISSION  CREW 
SELECT  AN  OPERATOR 


1.  Option  DISPLAY  MISSION  CREW 

Action:  Macro  Code 

{F9}W3G  ; ;  Go  to  window  *3  (mission  crew 

spreadshee  t ) 

2.  Option  SELECT  AN  OPERATOR 

Action:  Go  to  Menu  2 


MENU  2: 


SELECT  OPERATOR  TYPE 

ENTER  MISSION  DATE:  _ 

(YY.MM.DD) 

SELECT  ONE:  AMS  I=AA  2=MA  SS  MF  NMF  MR 

TRAINING  QUEUE  QUIT 


Option  ENTER  MISSION  DATE 

Action:  Mission  date  used  to  determine  op  availability 


Go 

to 

AMS  option 

2  . 

Option 

AMS 

Action: 

Go 

to 

Menu 

AMS 

3  . 

Opt i on 

AA 

Action: 

Go 

to 

Menu 

AA 

4  . 

Option 

MA 

Action : 

Go 

to 

Menu 

MA 

5  . 

Option 

SS 

Action: 

Go 

to 

Menu 

SP 

6  . 

Option 

MF 

Action : 

Go 

to 

Menu 

MF 

7  . 

Opt i on 

NMF 

Action: 

Go 

to 

Menu 

NMF 

8  . 

Option 

MR 

Action: 

Go 

to 

Menu 

MR 

9  . 

Option 

NMR 

Action: 

Go 

to 

Menu 

NMR 

10  . 

Option 

TRAINING  QUEUE 

Action: 

Macro 

Code 

{ VOFF } 

{F9} WIG 
{ESC} (ESC) 

S  C:\TKOPF\POSITION 

(75X) {DEL} 

TRNGQUE  NE  0 


TRNGQUE , A 


Turn  the  video  off 
Go  to  window  #  1  (data  base' 
Go  to  data  base  actions  men 
Sort  POSITION  relation 
2  Returns 

Delete  unwanted  charact 
Specification  for  data 
search 
Return 

First  sort  field,  ascend:  n / 

order 

Return 


*7 


r  r 


CHEW,  A 


POSITION. A 


(ESC> 
n 

{ 75X) (DEL) 

L ASTNAME { { } 14 { } } . 
FIRSTNAME ( t) llO) . 
CHEW{ ()5{) } . 
POSITION  (  { }9{ ) >  . 
TRNGQUE { { ) 7 { } } 

(VON) 

1  1  .  Option  QUIT 

Action:  Go  to  Menu  QUIT 


MENU  AMS : 

SELECT  ONE:  AMS  1=AMS  TRAINEE  2  =  AMS  I : 

1 .  Option  AMS 

Action:  Go  to  Menu  AMSCREW 

2.  Option  AMS  TRAINEE 

Action:  Go  to  Menu  AMSTCREW 

3.  Option  AMS  IRO 

Action:  Go  to  Menu  AMSICREW 


MENU  AA : 

SELECT  ONE:  AA  i=AA  TRAINEE  2=AA  IRO 


Second  sort  field,  ascending 

order 

Return 

Third  sort  field,  ascending 

order 
2  Returns 

Go  to  data  base  actions  menu 
Display  sorted  list 
2  Returns 

Delete  unwanted  characters 
Fields  to  display 


; ;  Return 

;  ;  Turn  video  back  on 


1 .  Option  AA 

Action:  Go  to  Menu  AACREW 

2.  Option  AA  TRAINEE 

Action:  Go  to  Menu  AATCREW 

3 .  Opt  ion  AA  IRO 

Action:  Go  to  Menu  AAICREW 
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MENU  MA : 


SELECT  ONE:  MA 

1  .  Option  M A 

Action:  Go  to  Menu  MACREW 

2.  Option  MA  TRAINEE 

Action:  Go  to  Menu  MATCREW 

3.  Option  MA  IRO 

Action:  Go  to  Menu  MAICREW 


MENU  SP: 

SELECT  ONE:  SS 

1.  Option  SS 

Action:  Macro  Code 

( VOFF }  ; 

{ F9 } WIG  ; 

{ &F9 ) D  ; 

POSITION  =  ' SS '  ; 

{ &F9 ) 0  : 

{ &F9 ) P  ; 

(VON)  ; 


2.  Option  SS  TRAINEE 

Action:  Macro  Code 

(VOFF) 

{ F9 } WIG 
( &F9 } D 

POSITION  =  'SS*  AND 

EXPLEVEL  =  0 
{ &F9 ) 0 

( &  F  9 )  P 
(VON) 


3.  Option  SS  I RO 

Action:  Macro  Code 

(VOFF) 

( F9) WIG 
{ &F9 )  D 
POSITION  = 


1 =  MA  TRAINEE  2  =  MA  IRO 


1=SS  TRAINEE  2=SS  IRO 


Turn  video  off 

Go  to  window  *1  (data  base) 

Call  DB  macro  procedure  D 

Specification  for  which  type 

ops  to  display 

Call  DB  macro  procedure  0 

Return 

Call  DB  macro  procedure  F 
Turn  video  on 


Turn  video  off 
Go  to  window  *1  (data  base 
Call  DB  macro  procedure  D 
Specification  for  which  type 
ops  to  display 

Call  DB  macro  procedure  0 
Return 

Call  D3  macro  procedure  F: 
Turn  video  on 


Turn  video  off 
Go  to  window  *1  idata  base 
Call  DB  macro  procedure  D 
Specification  for  which  type 


'SS'  AND 


TRAINER  =  YES 
{ &F9  >  0 

{&F9 }  ? 

(VON) 


ops  to  display 

Call  DB  macro  procedure  C 
Return 

Call  DB  macro  procedure  Q 
Turn  video  on 


MENU  MF: 


SELECT  ONE: 


MF  B/U 

2  =  MF  B/U  TRAINEE 
4  =  MF  B/U  IRO 


1 .  Option  MF  B/U 

Action:  Go  to  Menu  MF3CREW 

2.  Option  MF  B/U  TRAINEE 

Action:  Go  to  Menu  MFBTCREW 

3.  Option  MF  B/U  IRO 

Action:  Go  to  Menu  MFBICREW 

4.  Option  MF  LEAD 

Action:  Go  to  Menu  MFLCREW 

5.  Option  MF  LEAD  TRAINEE 

Action:  Go  to  Menu  MFLTCREW 

6.  Option  MF  LEAD  IRO 

Action:  Go  to  Menu  MFLICREW 


1 =MF  LEAD 
3  =MF  LEAD  T 
5  =  MF  LEAD  I.. 


i 

i 


j 

< 

< 

* 

■ 

i 


I 

i 

( 


MENU  NMF : 

SELECT  ONE:  NMF  B/U  1 =  NMF  LEAD 

2  =  NMF  B/U  TRAINEE  3  =  NMF  LEAD  TRAIN 

4  =NMF  B/U  IRO  5  =  NMF  LEAD  IRO 


1 .  Option  NMF  B/U 

Action:  Go  to  Menu  NMF3CREW 

2.  Option  NMF  B/U  TRAINEE 

Action:  Go  to  Menu  NMFBTCRE 

3.  Option  NMF  B/U  IRO 

Action:  Go  to  Menu  NMFBICRE 

4.  Option  NMF  LEAD 

Action:  Go  to  Menu  NMF LC HEW 

5.  Option  NMF  LEAD  TRAINEE 

Action:  Go  to  Menu  NMFLTCRE 
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6.  Option  NMF  LEAD  IRO 

Action:  Go  to  Menu  NMFLICRE 


MENU  MR: 

SELECT  ONE:  MR  B/U  1=MR  LEAD 

2  =  MR  B/U  TRAINEE  3  =  MR  LEAD  TRAINEE 

4  =  MR  B/U  IRO  5  =  MR  LEAD  IRO 

1 .  Option  MR  B/U 

Action:  Go  to  Menu  MRBCREW 

2.  Option  MR  B/U  TRAINEE 

Action:  Go  to  Menu  MRBTCREW 

3.  Option  MR  B/U  IRO 

Action:  Go  to  Menu  MRBICREW 

4.  Option  MR  LEAD 

Action:  Go  to  Menu  MRLCREW 

5.  Option  MR  LEAD  TRAINEE 

Action:  Go  to  Menu  MRLTCREW 

6.  Option  MR  LEAD  IRO 

Action:  Go  to  Menu  MRLICREW 


MENU  NMR : 

SELECT  ONE:  NMR  B/U  I =NMR  LEAD 

2= NMR  B/U  TRAINEE  3= NMR  LEAD  TRAINEE 

4  =NMR  B/U  IRO  5  =  NMR  LEAD  IRO 

1.  Option  NMR  B/U 

Action:  Go  to  Menu  NMRBCREW 

2.  Option  NMR  B/U  TRAINEE 

Action:  Go  to  Menu  NMRBTCRE 

3.  Option  NMR  B/U  IRO 

Action:  Go  to  Menu  NMRBICRE 

4.  Option  NMR  LEAD 

Action:  Go  to  Menu  N MRLCREW 

5.  Option  NMR  LEAD  TRAINEE 

Action:  Go  to  Menu  NMRLTCRE 

6.  Option  NMR  LEAD  IRO 

Action:  Go  to  Menu  NMRLICRE 


C-  17 


MENU  AMS CREW; 


SELECT  CREW;  ABLE  BAKER  CHARLIE  DAYS 

1 = ABLE  &  DAYS  2  =  BAKER  &  DAYS  3  =  CHARL I E  &  DAYS  4  =  ALL 

1  .  Opt  ion  ABLE 

Action:  Macro  Code 


{ VOFF } 

(F9) WIG 
( &F9 } D 

POSITION  =  'AMS'  AND 
CREW  =  ' A ‘ 

(&F9JO 

{ &F9  }  P 
(VON) 

2.  Option  BAKER 

Action:  Macro  Code 

{VOFF} 

(F9> WIG 
{ &F9 } D 

POSITION  =  ‘AMS’  AND 
CREW  =  ’B' 

{ &F9 } 0 

( &F9 } P 
(VON) 

3.  Option  CHARLIE 

Action:  Macro  Code 

{VOFF} 

{F9} WIG 
{ &F9 } D 

POSITION  =  ‘AMS’  AND 
CREW  =  '  C  ' 

{&F9 } 0 

{ &F9 } P 
{VON} 

4 .  Op  t i on  DAYS 

Action:  Macro  Code 

{VOFF} 

{F9} WIG 
{ &F9 } D 

POSITION  =  ” AMS ‘  AND 
CREW  =  ' D  ' 

( &F9 } 0 

{ &F9 } P 


Turn  video  off 

Go  to  window  *1  (data  base) 

Call  DB  macro  procedure  D 
Data  base  display  spec  i  f  1  ca  1 1  or. 

Call  DB  macro  procedure  0 
Return 

Call  DB  macro  procdure  P 
Turn  video  back  on 


Turn  video  off 

Go  to  window  #1  (data  base) 

Call  DB  macro  procedure  D 
Data  base  display  specification 

Call  DB  macro  procedure  0 
Return 

Call  DB  macro  procdure  ? 

Turn  video  back  on 


Turn  video  off 

Go  to  window  *1  (data  base) 

Call  DB  macro  procedure  D 
;  Data  base  display  specification 

Call  DB  macro  procedure  0 
Return 

Call  D3  macro  procdure  ? 

Turn  video  back  on 


Turn  video  off 

Go  to  window  #1  (data  base) 

Call  DB  macro  procedure  D 
;  Data  base  display  specification 

Call  DB  macro  procedure  0 
Return 

Call  D B  ma cro  procdure  P 
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{VON} 


Turn  video  back  on 


Option  ABLE  &  DAYS 
Action:  Macro  Code 


{ VOFF } 

(F9> WIG 
{ &F9 }  D 

POSITION  =  'AMS'  AND 
(CREW  =  " A '  OR 
CREW  =  ' D ‘ ) 

{&F9 }  0 

{ &F9 }  P 
(VON) 


Turn  video  off 

Go  to  window  #1  (data  base) 

Call  DB  macro  procedure  D 
;  Data  base  display  specification 


Call  DB  macro  procedure  0 
Return 

Call  DB  macro  procdure  ? 
Turn  video  back  on 


Option  BAKER  &  DAYS 
Action:  Macro  Code 


{VOFF} 

{F9} WIG 
{ &F9 }  D 

POSITION  =  "AMS'  AND 
(CREW  =  'B'  OR 
CREW  =  'D' } 

{ &F9 }  0 

{ &F9  }  P 
{VON} 


Turn  video  off 

Go  to  window  #1  (data  base) 

Call  DB  macro  procedure  D 
;  Data  base  display  specification 


Call  DB  macro  procedure  0 
Return 

Call  DB  macro  procdure  P 
Turn  video  back  on 


Option  CHARLIE  &  DAYS 
Action:  Macro  Code 


{VOFF} 

{F9} WIG 
{ &.F9  }  D 

POSITION  =  'AMS'  AND 
(CREW  =  *C'  OR 
CREW  =  ' D ' ) 

{ &F9 }  0 

{ &F9 }  P 
{VON} 


Turn  video  off 

Go  to  window  #1  (data  base) 

Call  DB  macro  procedure  D 
;  Data  base  display  specification 


Call  DB  macro  procedure  0 
Return 

Call  DB  macro  procdure  P 
Turn  video  back  on 


Option  ALL 
Action:  Macro  Code 


{VOFF} 
{F9} WIG 
{ &F9 }  D 
POSITION 
{ &F9 }  0 

{ &F9 }  P 
{VON} 


'AMS'  AND 


Turn  video  off 

Go  to  window  #1  (data  base) 

Call  DB  macro  procedure  D 
Data  base  display  specification 
Call  DB  macro  procedure  0 
Re  turn 

Call  DB  macro  procdure  ? 

Turn  video  back  on 
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MENU  AMS  I CREW: 

SELECT  CREW:  ABLE 
1 =  ABLE  &  DAYS 


BAKER  CHARLIE  DAYS 

2  =  BAKER  &  DAYS  3  =  CHARL I E  &  DAYS 


Option  ABLE 
Action:  Macro  Code 

{ VOFF } 

(F9> WIG 
{ &F9 } D 

POSITION  =  " AMS 
CREW  =  'A'  AND 
TRAINER  =  YES 
{ &F9 } 0 

{ &F9 } P 
(VON) 

Option  BAKER 
Action:  Macro  Code 

{VOFF} 

(F9) WIG 
{ &F9 } D 

POSITION  =  'AMS 
CREW  =  -B"  AND 
TRAINER  =  YES 
{ &F9 } 0 

{ &F9 } P 
{VON} 

Option  CHARLIE 
Action:  Macro  Code 

{VOFF} 

{F9} WIG 
{ &F9 } D 

POSITION  =  "AMS 
CREW  =  *C‘  AND 

TRAINER  =  YES 
{ &F9 } 0 

{ &F9 } P 
(VON} 

Option  DAYS 
Action:  Macro  Code 

{VOFF} 

{ F  9  }  W  i  G 
{ &F9 } D 

POSITION  =  "AMS 


Turn  video  off 

Go  to  window  #1  (data  base; 

Call  DB  macro  procedure  D 
;  Data  base  display  specification 


Call  DB  macro  procedure  0 
Return 

Call  DB  macro  procedure  Q 
Turn  video  back  on 


Turn  video  off 

Go  to  window  #1  (data  base) 

Call  DB  macro  procedure  D 
;  Data  base  display  spec  1 f i cat i on 


Call  DB  macro  procedure  0 
Return 

Call  DB  macro  procedure  Q 
Turn  video  back  on 


Turn  video  off 

Go  to  window  #1  (data  base) 

Call  DB  macro  procedure  D 
Data  base  display  spec i f i cat : on 


Call  D3  macro  procedure  0 
Return 

Call  DB  macro  procedure  Q 
Turn  video  back  on 


Turn  video  off 
Go  to  window  *1  (data  base’ 
Call  DB  macro  procedure  D 
Data  base  display  specific 


C  -  20 
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TRAINER  =  YES 
(&F9J0 

{ &F9 } P 
{VON} 

Option  ABLE  &  DAYS 
Action:  Macro  Code 

C  VOFF } 

(F9) WIG 
{ &F9 } D 

POSITION  =  "AMS'  AND 
(CREW  =  'A'  OR 

CREW  =  *  D  * )  AND 
TRAINER  =  YES 
{ &F9 } 0 

{ &F9 } P 
{VON} 

Option  BAKER  &  DAYS 
Action:  Macro  Code 

{VOFF} 

{F9} WIG 
{ &F9 }  D 

POSITION  =  " AMS "  AND 
(CREW  =  " B  *  OR 

CREW  =  "D" )  AND 
TRAINER  =  YES 
{ &F9 } 0 

{&F9 } P 
{VON} 

Option  CHARLIE  &  DAYS 
Action:  Macro  Code 

{VOFF} 

{F9} WIG 
{ &F9 }  D 

POSITION  =  "AMS'  AND 
(CREW  =  "C"  OR 
CREW  =  'D' )  AND 
TRAINER  =  YES 
{ &F9 } 0 

{ &F9 } ? 

{VON} 

Option  ALL 
Action:  Macro  Code 


Call  DB  macro  procedure  j 
Re  turn 

Call  DB  macro  procedure  3 
Turn  video  back  on 


Turn  video  off 
Go  to  window  #1  (data  base) 
Call  DB  macro  procedure  D 
;  Data  base  display  specific 


Call  DB  macro  procedure  0 
Return 

Call  DB  macro  procedure  3 
Turn  video  back  on 


Turn  video  off 
Go  to  window  #1  (data  base) 
Call  DB  macro  procedure  D 
;  Data  base  display  specific 


Call  DB  macro  procedure  0 
Return 

Call  DB  macro  procedure  3 
Turn  video  back  on 


Turn  video  off 
Go  to  window  #1  (data  base 
Call  DB  macro  procedure  D 
;  Data  base  display  specific 


Call  DB  macro  procedure  0 
Return 

Call  DB  macro  procedure  3 
Turn  video  back  cn 


l.-it 
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{ VOFF) 

{F9} WIG 
{&F9)D 

POSITION  =  'AMS"  AND 
TRAINER  =  YES 
{ &F9 } 0 


Turn  video  of: 

Go  to  window  -  1  (data  base. 
Call  DB  macro  procedure  D 
;  Data  base  display  soecir'ica- 


{ &F9 }  P 
(VON) 


Cali  D3  macro  procedure  0 
Return 

Call  DB  macro  procedure  Q 
Turn  video  back  on 


MENU  AMSTCREW: 


SELECT  CREW:  ABLE 
1  = ABLE  &  DAYS 


3 AKER  CHARLIE  DAYS 

2  =  BAKER  &  DAYS  3  =  CHARLI E  &  DAYS 


Option  ABLE 
Action:  Macro  Code 


(VOFF) 

(F9) WIG 
{ &F9 } D 

POSITION  =  "AMS 
CREW  =  "A"  AND 

EXPLEVEL  =  0 
{ &F9 } 0 


Turn  video  off 

Go  to  window  #1  (data  base) 

Call  DB  macro  procedure  D 
Data  base  display  specificati: 


{&F9JP 

{VON} 


Call  DB  macro  procedure  0 
Return 

Call  DB  macro  procedure  R 
Turn  video  back  on 


Option  BAKER 
Action:  Macro  Code 


(VOFF) 

{F9> WIG 
{ &F9 } D 

POSITION  =  "AMS 
CREW  =  'B*  AND 
EXPLEVEL  =  0 
{ &F9 } 0 


Turn  video  off 
Go  to  window  #1  (data  ba 
Call  DB  macro  procedure 
Data  base  display  specification 


{ &F9 ) P 
(VON) 


Cali  DB  macro  procedure  0 
Return 

Call  DB  macro  procedure  R 
Turn  video  back  on 


Option  CHARLIE 
Action:  Macro  Code 


{VOFF} 

{F9}  WIG 
{ &F9 } D 

POSITION  =  "AMS 
CREW  =  "C"  AND 
EXPLEVEL  =  0 


Turn  video  off 
Go  to  window  *1  (data  base 
Call  DB  macro  procedure  D 
Data  base  display  specification 
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{ &F9  >  0 


(&F9JP 
( VON) 

Option  DAYS 
Action:  Macro  Code 

{ VOFF} 

(F9) WIG 
(&F9) D 

POSITION  =  'AMS'  AND 
CREW  =  'D'  AND 
EXPLEVEL  =  0 
{ &F9 } 0 

{&F9 } P 
(VON) 

Option  ABLE  &  DAYS 
Action:  Macro  Code 

(VOFF) 

CF9} WIG 
{ ScF9 }  D 

POSITION  =  'AMS'  AND 
(CREW  =  'A'  OR 

CREW  =  'D* )  AND 
EXPLEVEL  =  0 
{ &F9 } 0 

{ &F9 } P 
{VON} 

Option  3AKER  &  DAYS 
Action:  Macro  Code 

(VOFF) 

(F9) WIG 
{ &F9 } D 

POSITION  =  'AMS'  AND 
(CREW  =  *B"  OR 
CREW  =  ' D' )  AND 
EXPLEVEL  =  0 
{ 8cF9 }  0 

{ &F9 } P 
(VON) 

Option  CHARLIE  &  DAYS 
Action:  Macro  Code 

(VOFF) 

<F9> WIG 
{ &F9 } D 


Call  D B  aa c r o  procedure  1 
Return 

Call  DB  macro  procedure  R 
Turn  video  back  on 


Turn  video  off 
Go  to  window  *  1  (data  base 
Call  DB  macro  procedure  D 
;  Data  base  display  specifi 

Call  DB  macro  procedure  0 
Return 

Call  DB  macro  procedure  ?. 
Turn  video  back  on 


Turn  video  off 
Go  to  window  #1  (data  base 
Call  DB  macro  procedure  D 
;  Data  base  display  specif; 


Call  DB  macro  procedure  0 
Return 

Call  DB  macro  procedure  R 
Turn  video  back  on 


Turn  video  off 
Go  to  window  #1  (data  base 
Call  DB  macro  procedure  D 
;  Data  base  display  specif i 


Call  DB  macro  procedure  0 
Return 

Call  DB  macro  procedure  R 
Turn  video  back  on 


Turn  video  off 

Go  to  window  *1  (data  base 

Call  DB  macro  procedure  D 


■VW  «  w*t  w  «. 


position  =  'am: 

(CREW  =  "C  OR 
CREW  =  •  D  '  )  a: 
EXPLEVEL  =  0 
{ &F9 } 0 

( &F9 } P 
{VON} 

Option  ALL 
Action:  Macro  Code 


{ VOFF } 
(F9> WIG 
{ &F9 } D 
POSITION 
EXPLEVEL 
( &F9 } 0 


Cali  D9  macro  procedure  0 

Return 

Call  DB  macro  procedure  R 
Turn  video  back  on 


' AMS ‘  AND 

0 


{ &F9 }  P 
{VON} 


Turn  video  off 
Go  to  window  #1  (data  base 
Call  DB  macro  procedure  D 
Data  base  display  specif:: 

Call  DB  macro  procedure  0 
Return 

Call  DB  macro  procedure  R 
Turn  video  back  on 


MENUS:  AACREW,  AAICREW,  AATCREW,  MACREW,  MAICREW,  MATCREW, 

MFBCREW,  MFBICREW ,  MFBTCREW ,  MFLCREW,  MFLICREW,  MFLTCREW , 
NMFBCREW,  NMFBICRE ,  NMFBTCRE ,  N MFLCREW,  NMFLICRE ,  NMFLTCRE , 
MRBCREW ,  MRBICREW,  MRBTCREW ,  MRLCREW,  MRLICREW,  MRLTCREW , 
NMRBCREW,  NMRBICRE .  NMRBTCRE .  N MRLCREW,  NMRLICRE,  NMRLTCRE 

All  the  above  menus  follow  the  same  basic  pattern  as  that 
described  for  the  AMS  series  of  menus.  Therefore,  separate 
entries  for  these  menus  will  not  be  made. 


MENU  S : 

MISSION  SCHEDULE  MENU 

DISPLAY  MISSION  SCHEDULE 
ADD  MISS  ION ( S )  TO  SCHEDULE 
CHANGE  MISSION  SCHEDULE 


Option  DISPLAY 
Action:  Go  to  Menu  DSPLYMSN 

Option  ADD 
Action:  Macro  Code 


{F9} WIG 
{ESC} (ESC) 
A  MISSION 
( 2  5X }  (DEL) 


Go  to  window  #1  (data  base 
Go  to  data  base  actions  me: 
Add  to  MISSION  relation 
Delete  unwanted  characters 
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Ret  ur : 


Option  CHANGE 
Action:  Go  to  Menu  CHNGMSN 


MENU  DSPLYMSN : 


ENTER  START  DATE: 


(YY .MM.DD) 


K 


1 .  Opt  ion  ENTER 

Action:  Macro  Code 

(F9) WIG 
(ESC) (ESC) 

D  MISSION 
( 25X) (DEL) 

DATE  GE  '  [7.STARTDT  ] 


NUMBER, TYPE, DATE. 
TAKEOFF , LAND . 
SHOWTIME 


Go  to  window  #1 
Go  to  data  base 
Display  MISSION 
Delete  unwanted 
2  Returns 
;  Specification 
missions  to  1 
Return 

Fields  to  display 


(data 
action 
r  e  1  a  1 1 
char ac 


base 
s  men- 
on 

ter  s 


for 
l  s  t 


wh  i  c! 


MENU  CHNQMSN : 


ENTER  MISSION  NUMBER; 


Option  ENTER 

Action:  Macro  Code 


i*, 


r»‘ 


(F9)  WIG 
(ESC) (ESC) 

E  MISSION 
{ 25X} (DEL) 

NUMBER  =  [  7.MSNNBR  ] 


Go  to  window  *1  (data  base! 

Go  to  data  base  actions  menu 
Edit  MISSION  relation 
Delete  unwanted  characters 
3  Returns 

;;  Specification  of  which  mission 
to  edit 
2  Returns 


MENU  U: 


OPERATOR  UPDATE  MENU 

WOULD  YOU  LIKE  TO: 

ADD  A  RECORD 
CHANGE  A  RECORD 
DELETE  A  RECORD 


Option  ADD 

Action:  Go  to  Menu  ADD 


Option  CHANGE 
Action:  Go  to  Menu  CHANGE 

Option  DELETE 
Action:  Go  to  Menu  DELETE 


MENU  ADD 


OPERATOR  ADD  MENU 

ENTER  OPERATOR'S  LAST  NAME:  _ 

AVAILABILITY 

I =  ADD  A  NEW  OPERATOR  TO  THE  DATA  BASE 

YOUR  CHOICE  WILL  TAKE  YOU  TO  THE  APPROPRIATE  DATA  BASE.  TO  ADD  AN 
OPERATOR.  SIMPLY  TYPE  IN  THE  APPROPRIATE  INFORMATION  AS  IT  IS 
REQUESTED.  IF  TIS  IS  A  BRAND  NEW  OP  AND  YOU  ARE  SETTING  UP  NEW  RECO 
YOU  WILL  GO  TO  THE  OPERATOR  DATA  BASE  FIRST.  AFTER  YOU  ARE  FINISHED 
ENTERING  THE  DATE.  SAVE  IT.  THEN  QUIT  (FIO  SAVE/QUIT).  CHOOSE  AID 
AGAIN  BUT  TYPE  IN  POSITION  AT  THE  WHICH  DATA  BASE  PROMPT.  THEN  HIT 
RETURN  3  TIMES.  YOU  NOW  MAY  ENTER  THE  REST  OF  THE  OPERATOR  I NFORMAT 


Option  AVAILABILITY 
Action:  Macro  Code 

(F9)  WIG 
(ESC) (ESC) 

A  ABSENT 
{ 20X} (DEL) 


L  2 .  Opt  ion  ADD 

B  Action:  Macro  Code 

rj 

V  { F9 ) Wl G 

v  (ESC) (ESC) 

£  A  OPERATOR 

y  { 20X } (DEL } 


Go  to  window  #1  (data  base) 
Go  to  data  base  actions  menu 
Add  to  the  ABSENT  relation 
Delete  unwanted  characters 
3  Returns 


Go  to  window  #1  (data  base) 
Go  to  data  base  actions  menu 
Add  to  the  OPERATOR  re  la: ion 
Delete  unwanted  characters 
3  Returns 
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MENU  CHANGE : 


OPERATOR  CHANGE  MENU 
ENTER  OPERATOR’S  LASTNAME :  _ 


AVAILABILITY 

SS  AN 

NAME 

RANK 

CREW 

OPERATOR  TYPE 
PRIMARY  POSITION 


QUALIFICATION 
TRAINER  QUAL 

1  =TRAINEE  PRIORITY 

2  =  TRA I NER  STRENGTHS 
EXPERIENCE  LEVEL 

3  =  STAN/ EVAL  DATE 


YOUR  CHOICE  WILL  TAKE  YOU  TO  THE  APPROPRIATE  DATA  BASE.  TO  ORANGE  A 
RECORD  (EDIT) ,  SIMPLEY  MARK  THE  APPROPRIATE  RECORD  USING  THE  F~  FUNCTI 
KEY,  PRESS  ESC  TWICE,  THEN  PRESS  ' E ' .  THE  RECORD  CAN  NOW  BE  CHANGED 
*#*#  NOTE.  IF  YOU  CHANGE  THE  SSAN,  YOU  MUST  CHANGE  IT  IN  ALL  RELATIONS 


Option  AVAILABILITY 
Action:  Macro  Code 


(F9) WIG 
{ &F9 }  6 


Go  to  window  #1  (daia  base) 
Call  DB  macro  procedure  6 


Option  SSAN 
Action:  Macro  Code 


(F9)  WIG 
(ESC) (ESC) 
D 


Go  to  window  *1  (data  base) 
Go  to  data  base  actions  menu 
Display  data  base 


Option  NAME 
Action:  Macro  Code 


(F9) WIG 
{ &F9 }  4 


;;  Go  to  window  #1  (data  base; 
; ;  Call  DB  macro  procedure  4 


Option  RANK 

Action:  Macro  Code  (same  as  Option  NAME) 


Option  CREW 

Action:  Macro  Code  (same  as  Option  NAME) 


Option  OPERATOR  TYPE 
Action:  Macro  Code  (same  as  Option  NAME) 


Option  PRIMARY  POSITION 
Action:  Macro  Code 


(F9) WIG 
{&F9} 5 


; ;  Go  to  window  #1  (data  base) 
; ;  Call  DB  macro  procedure  5 


Option  QUALIFICATION 

Action:  Macro  Code  (same  as  Option  PRIMARY  POSITION) 
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I  r. 


9  . 


''  p  t i  o  n 


Action: 

Option 
Ac  t ion: 


Option 

Action: 

Option 
Action : 


Ma 

cro 

T 

ode 

3 

a  me 

TRAI 

NEE 

p 

HI  OR 

m 

Y 

Ma 

cro 

c 

ode 

3 

a  me 

TRAI 

NER 

3 

TRENGT 

HS 

Ma 

cro 

C 

ode 

( s 

ame 

EXPERIENCE  LEVEL 
Macro  Code  (sane 


a  3 


as 


as 


as 


Option  ? I  MAP. Y  PTOI 
Option  PRIMARY  ?  1 .1 1 
Option  PRIMARY  POE  I 
Option  PRIMARY  PCS  I 


13  . 


Option  STAN/EVAL  DATE 

Action:  Macro  Code  (same  as  Option  PRIMARY  PCS  I 


MENU  DELETE: 


OPERATOR  DELETE  MENU 
ENTER  OPERATOR'S  LASTNAME : 


AVAILABILITY 
1 = ALL  OPERATOR  RECORDS 


YOUR  CHOICE  WILL  TAKE  YOU  TO  THE  APPROPRIATE  DATA  B A3 
RECORD: 


I  ) 

MARK  T 

HE  APPROPRIATE  RECORD 

2) 

PRESS 

'  ESC  "  2 

TIMES 

3) 

PRESS 

'  1  ' 

4) 

PRESS 

' RETURN 

'  2  TIMES 

5) 

PRESS 

*ESC'  2 

TIMES 

6) 

PRESS 

‘  6  ' 

7) 

PRESS 

‘ RETURN 

‘  3  TIMES 

1.  Option  AVAILABILITY 

Action:  Macro  Code  (same  as  Option  AVAILABILITY 


2.  Option  ALL  OPERATOR  RECORDS 

Action:  Macro  Code  (same  as  Ootion  PRIMARY  POSI 


MENU  C : 


MISSION  COMPLETION  MENU 

UPDATE  MISSION  HISTORY  DATA  BASE 
1 =  UPDATE  OPERATOR  FLIGHT  HISTORY  DATA  BASE 
2  =  UPDATE  30/90  DAY  FLIGHT  HOUR  TOTALS 
30  DAY  UPDATE 
90  DAY  UPDATE 

ADD  INDIVIDUAL  HOURS  ( E - 3A . C -  1 30 . ETC .  ) 
RETURN  TO  MAIN  MENU 


Option  UPDATE  MISSION  HISTORY  DATA  EASE 
Action:  Macro  Code 


{  F  9  ;  W 1  G 
(ESC) (ESC) 
A  MSMHISTY 
{ 15X) (DEL) 


Go  to  window  *1 
Go  to  data  base 
Add  to  MSNHISTY 
Delete  unwanted 
3  Returns 


'data  b a  s 
actions  m 
relation 
character 


:e 


Option  UPDATE  OPEATOR  FLIGHT  HISTORY  DATA  BASE 
Action:  Go  to  Menu  OP HI STY 


Option  30  DAY  UPDATE 
Action:  Macro  Code 


{ VOFF } 

{ &HOME } USR  THIRTY" 


{F9> WIG 
{ESC) (ESC) 

S 

(VON) 

( &F9 }  1 
{ F9 } W3G 
(VOFF) 

{ F2 } H4  ~ 

{ &F9 }  H 

{ &HOME } USR  HOURS3" 

( F2 ) A4  ~ 

{ &F9 )  R 
(F9) WIG 
(ESC) (ESC) 

U 

{ &F9 }  2 
{ F9 } W4G 

( F2 ) A4~ 

(FIO)WRE. 

(RIGHT) (END) (DOWN) 

( &F 10) ~R 

(&END) Y 

{ F9 ) W3G 

{ &END )  Y 

(VON) 

( * F10)C 


’ u  * 


Turn  video  off 
Open  window  with 
spreadsheet 

Go  to  window  *1  (data  base 
Go  to  data  base  actions  me: 
Sort 

Turn  video  on 

Call  DB  macro  procedure  1 

Go  to  window  *3  (THIRTY. SS) 

Turn  video  off 

Put  cursor  in  space  H4  in 

preparation  for  data  trans 

Call  SS  macro  procedure  H 

Open  window  with  H0URS3.SSF 

spreadsheet 

Put  cursor  m  space  A4  m 
preparation  of  data  transfe 
Call  SS  macro  procedure  R 
Go  to  window  «1  (data  base 
Go  to  data  base  actions  me; 
Update 

Call  DB  macro  procedure  2 
Go  to  window  *4  (H0URS3.SS: 
Position  cursor  m  prepara* 
to  delete  data 
Erase  data  from  H0URS3.S2F 


Save  ’clean'  f i 
Close  wi ndow 
Go  to  window  «3 
Close  window 
Turn  video  on 
Go  to  Menu  C 


e  (HOURS 3.: 
(THIRTY .S3: 


Option  90  DAY  UPDATE 
Action:  Macro  Code 


7urn  v  i  d o  o  i  i 

Open  window  w  i  *.  h  >.’  I  N  E  T  Y  .  3  3  r 


(VOFF) 

(& HOME) USR  NINETY 


(F9) WIG 
(ESC) (ESC) 

S 

(VON) 

{ &F9 }  1 
{F9} W3G 
{ VOFF } 

{F2} H4~ 

{ &F9 } H 

{ &HOME } USR  HOURS9~ 

{ F2 } A4~ 

{ &F9 } R 
{F9} WIG 
{ESC} {ESC} 

U 

{&F9} 3 
{F9} W4G 
{ F2 } A4~ 

{ F 1 0 } WRE . 

{RIGHT} {END} {DOWN} 

{ &F  10) ~R 
{ &END } Y 
( F9 } W3G 
{ &END } Y 
{VON} 

{  '  F  1 0 }  C 

5.  Option  ADD  INDIVIDUAL  HOURS 
Action:  Macro  Code 


spreadsheet 

;  Go  t  o  window  »  1  z  t  a  base 
:  Go  to  data  base  actions  men 
;  Sort 

;  Turn  video  or. 

;  Call  D3  macro  procedure  . 

;  Go  to  window  *3  (NINETY. S3F 
;  Turn  video  off 

;  Put  cursor  m  space  H4  m 

preparation  for  data  transf 
:  Call  SS  macro  procedure  H 
;  ;  Open  window  with  H0URS9.SSF 
spreadsheet 

Put  cursor  in  space  A4  ir. 
preparation  of  data  trar.sfe 
Call  SS  macro  procedure  ?. 

Go  to  window  #1  (data  base' 
Go  to  data  base  actions  men 
Update 

Call  DB  macro  procedure  3 
Go  to  window  #4  (HCURSS.SSF 
Position  cursor  in  prepara t 
to  delete  data 
Erase  data  from  H0URS9.SSF 

Save  ‘clean"  file  (H0URS9.S 
Close  window 

Go  to  window  #3  (NINETY. SSF 
Close  window 
Turn  video  on 
Go  to  Menu  C 


{F9} WIG 
{ESC} {ESC} 
A  OPHISTY 
{ 15X} {DEL} 


6.  Option  RETURN 

Action:  Go  to  Menu  N 


MENU  OPHISTY: 

ENTER  MISSION  NUMBER: 


1.  Option  ENTER 

Action:  Macro  Code 

{ &H0ME } USR  :%MISSI0N}~  ;;  Open  window  with  enter 


Go  to  window  «i  (data  base' 
Go  to  data  base  actions  men 
Add  to  OPHISTY  relation 
Delete  unwanted  characters 
3  Returns 


C  -  3  3 


VF*  FXTOWW  V  nr  WJ"  pv  a  ■  -%  j~w 


•F2} A5~ 

1  St  HO  ME)  USR  MSNDONE 

(&F9)U 
{F9}  WIG 
(ESC) (ESC) 

C  OPHISTY 
( 15X> (DEL) 

F  E  MSNDONE. SSF 


{ F9 )  W4G 
{ F2 } A4~ 

<F10) WRE. 

C  4X> {RIGHT} 
(END) (DOWN) ~ 
( &F 10} ~R 

(&END}  Y 
{ F9 }  W3G 
{&END}  Y 
{  "  F  1 0 }  C 


mission  crew  spreadsheet. 

;  ;  Position  cursor  at  position  At 
; ;  Open  window  with  MSUD2NE.SSF 
spreadsheet 

;  ;  Cali  S S  macro  procedure  Y 
;  ;  Go  to  window  #1  (data  base. 

;  ;  Go  to  data  base  actions  menu 
;  ;  Copy  into  OPHISTY  relation 
;  ;  Delete  unwanted  characters 
;  ;  Re  turn 

;  ;  Copy  data  from  MSNDONE. SSF  t: 

OPHISTY  relation 
;  ;  3  Returns 

;;  Go  to  window  *4  l MSNDONE . SSF ' 

;  ;  Position  cursor  at  position  A4 
in  preparation  for  clearing  data 
;  ;  Erase  data  from  MSNDONE. SSF 


;;  Save  'clear'  spreadsheet 
(MSNDONE . SSF) 

;;  Close  window  #4  ( MSNDONE . SSF ) 

;  ;  Go  to  window  *3  l  1  */.MI  SSI  ON  1  .SSF 
;  ;  Close  window  *3 
;  ;  Go  to  Menu  C 


MENU  MI SC: 

MISCELLANEOUS  MENU 
SV-83 

FLIGHT  PHYSICAL 
LIFE  SUPPORT 
PHYSIOLOGICAL  TRAINING 


1 .  Option  SV-83 

Action:  Macro  Code 

{F9}W1G  ; ;  Go  to  window  *1  (data  base 

{&F91X  ; ;  Call  DB  macro  procedure  X 

2.  Option  FLIGHT  PHYSICAL 

Action:  Macro  Code  (same  as  Option  SV-83) 

3.  Option  LIFE  SUPPORT 

Action:  Macro  Code  (same  as  Option  SV-83) 

4.  Option  PHYSIOLOGICAL  TRAINING 

Action:  Macro  Code  (same  as  Option  SV-83 


MENU  F:  (FLIGHT  ORDERS) 


■ 


FLIGHT  ORDERS 
ENTER  MISSION  NUMBER: 


HAVE  YOU  WORKED  ON  THESE 
ORDERS  3EF0RE ? 

YES  NO 


Option  ENTER 

Action:  Go  to  Option  YES  after  typing  mission  number 

Option  YES 
Action:  Macro  Code 


{ &HOME } UWR 
{  ~  F  1 0  }  I 

3 .  Opt  ion  NO 

Action:  Macro  Code 


Open  window  with  [ %MI SS ION ] . WP 
word  processing  file 
Go  to  Menu  I 


{ &HOME } UWC 


{ 3X) { UP }  { &F3 }  ; 

(&HOMEJUSR  ORDERS ~  ; 

{ &HOME }  USR  [‘/.MISSION] 

{ F2 ) C I ~  ; 

{ F9 ) W4G  ; 

{ &F9 ) K  ; 

(F91W5G  ; 

{ &END } Y  ; 

( F9 } W3G  ; 

{ &F9 } F  ; 


Open  window  with  [ ‘4MI SS I  ON ]  . WP 
word  processing  file 
2  Returns 

Delete  Document  Title  line 
Open  window  with  ORDERS. SSF 
spreadsheet 

; ;  Open  window  with 

[‘/.MISSION]  .  SSF  spreadshee 
Position  cursor  at  position  Cl 
Go  to  window  #4  (ORDERS. SSF) 
Call  SS  macro  procedure  X 
Go  to  window  #5  ( [ %MI SS ION ] . SS 

Close  window  #5 

Go  to  window  #3  (  [  */.MI  S3  I  ON  ]  .  WF 
Call  WP  macro  procedure  F 


MENU  G: 


ENTER  THE  EXPECTED  LAND  DATE 


AND  HIT  RETURN 


Option  ENTER 
Action:  Macro  Code 

Go  to  [% MISSION] . W?  F  file 
Insert  expected  land  date 
Call  WP  macro  procedure  G 


[‘/.LAND  ]~ 
{ &F9 }  G 


C  -  32 


' l’,k»  ,»  • 

L."  K-T  - 


MENU  H: 


ENTER  THE  DATE  AND  TAKEOFF  TIME  IN 
THE  FOLLOWING  FORMAT:  15  MAR  87/  05001 


HIT  RETURN 


Option  ENTER 

Action:  Macro  Code 

(ESC) 

C  ‘/.TAKEOFF 
( &F9 ) H 


Go  to  [“/.MISSION!  .  WPF  file 
Insert  expected  takeoff  time 
Call  WP  macro  procedure  H 


MENU  I : 


ENTER  TODAY'S  DATE 


HIT  RETURN 


1  .  Op  t i on  ENTER 

Action:  Macro  Code 


(ESC) 

[“/.TODAY  3 ~ 

( 60X) (RIGHT) (UP) 
(&F9) J 


Go  to  [“/.MISSION]  .  WPF  file 
Insert  today's  date 
Position  cursor 
Call  WP  macro  procedure  J 


MENU 


ENTER  THE  ORDER  NUMBER 


HIT  RETURN 


1,  *, 


Option  ENTER 

Action:  Macro  Code 


r  ESC ) 

[  7.0RDNBR  ]  ~ 

{ 13X) (RIGHT) 
6916ESS~ 

( 13X) (RIGHT) 
HELLENIKON  AB ,  GR" 

( 50X) (RIGHT) 

C.T.  FRENCH,  LTCOL , 
{ 50X)  (RIGHT) 
OPERATIONS  OFFICER 
(  *F10)K 


;;  Go  to  [  “/.MI  SS I  ON  ]  .  WPF  file 
; ;  Insert  Order  Number 
;;  Position  cursor 
;;  Insert  6916ESS 
; ;  Position  cursor 
;;  Insert  HELLENIKON  AB ,  GR 
; ;  Position  cursor 

USAF~  ;;  Enter  Ops  Officer’s  name 
;;  Position  cursor 
; ;  Insert  OPERATIONS  OFFICER 
; ;  Go  to  Menu  K 


‘  J»‘  '  J|‘  JU*  ‘t.« 


MENU 


ll'd-'J.UJ. 


WOULD  YOU  LIKE  TO  EXAMINE  THE  ORDERS  OR  MAKE  CHANGES 


Option  YES 

Action:  Go  to  Menu  ORDCHG 

Option  NO 

Action:  Go  to  Menu  PRINT 


MENU  ORDCHG: 


WHEN  YOU  ARE  DONE,  PRESS  CTRL/F10  THEN  X 


HIT  RETURN  TO  CONTINUE 


Option  CONTINUE 
Action:  Macro  Code 

(ESC) 


;;  Go  to  word  processing  file 


MENU  PRINT: 


FLIGHT  ORDERS  PRINT  MENU 


WOULD  YOU  LIKE  TO  PRINT  THE  FLIGHT  ORDERS' 


Option  YES 

Action:  Go  to  Menu  PRINT2 

Option  NO 

Action:  Go  to  Menu  ORDCHG 


MENU  PRINT2: 


INSERT  ORDERS  IN  THE  PRINTER  AND  HIT  RETURN  WHEN  READY 


1.  Option  INSERT 

Action:  Macro  Code 


C  -  3  4 


/.a 


f  ./ c  • **  •  o  *  • 
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